feat: support parsing base32 and base36 libp2p-key CIDs in peerIdFromString

[2color]

Title

Given the prevalence of both CID encoded PeerIDs and base58mh encoded ones, I found myself defining this function in multiple places.

This PR introduces this as a helper (as was supported in an earlier version of js-libp2p)

Notes & open questions

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[achingbrain]

Looking at the utility functions exported by this module, if I have a string and I want a PeerId it would not be obvious to me whether to call peerIdFromString or this new getPeerId function.

Given that the spec mentions base32 (not base36 as in the comment here) encoded libp2p-key CIDs as a canonical string encoding, let's check form that prefix in peerIdFromString instead.

[2color]

Given that the spec mentions base32 (not base36 as in the comment here) encoded libp2p-key CIDs as a canonical string encoding, let's check form that prefix in peerIdFromString instead.

Do you mean checking the multibase prefix in the string for b and decoding it as a CID if it is in the peerIdFromString function?

Regarding base36 cids, I realise it's not in the peerIDs spec, but it's the standard string form for ipns names. Do you feel strongly about not including it here?

[achingbrain]

Do you mean checking the multibase prefix in the string for b

Yes, but with few more characters to include the libp2p-key codec in the check so we are more sure it's a CID.

it's the standard string form for ipns names. Do you feel strongly about not including it here?

Groan. The usual reason not to include lots of different base encoder/decoders is because they bloat bundle sizes but I suppose here we have a dependency on the CID class so base36 is in there anyway.

[2color]

Yes, but with few more characters to include the libp2p-key codec in the check so we are more sure it's a CID.

This turned out to be rather confusing. I took a look at the string encoding of cids and I'm not sure I got the right prefix characters for base36/base32 CID encoded public keys.