fix: add isCryptographicIPNS check for ipns-ns

[lidel]

@makoto @Arachnid
This is a PoC that makes migration away from non-cryptographic identifiers in ipns-ns (ensdomains/ens-app#849 (comment) less painful:

• decoding legacy non-cryptographic values in ipns-ns + printing deprecation warning
• not allowing new ones to be encoded

👉 this PR as a starting point for a discussion, do not merge it.

• I don't like how hacky detection of inlined names is, but this is the only way to correctly decode string like app.uniswap.org in your GUI web app and at the same time refuse to encode a non-libp2p-key string inlined inside Base58 multihash.

• I am not sure if we should pollute this library with workarounds for things that should be either in web interface at ens-app or in the at the contract level (if ENS did CID validation at the contract level, it would never allow names in the first place).

  • ❓ namely, this library throws on strings app.uniswap.org, so it receives app.uniswap.org already encoded as an identity multihash with value inlined as digest – where is this happening?
    • I suspect that if ens-app passed original identifier as-is, and did not turn it to Base58, then this entire PR would not be necessary.

lmk your thought on this

[makoto]

Hi, @lidel . I tried test integration on app-ens and worked fine.

I am not sure if we should pollute this library with workarounds for things

Given this library seems used at other apps like Metamask, probably better to keep it here.

I suspect that if ens-app passed original identifier as-is, and did not turn it to Base58, then this entire PR would not be necessary

True, though given uniswap already used the old code, I assume it would fail without it?

I could merge this after tidying up a few indentations, etc.

[lidel]

Given this library seems used at other apps like Metamask, probably better to keep it here.

Fair point. In that case let's fix this here.
I cleaned this up in adff4af, should be easier to audit and maintain.

@makoto Feel free to review / tweak as needed.

True, though given uniswap already used the old code, I assume it would fail without it?

I sadly have no bandwidth for testing that, but possible.
So I guess this PR is our best bet to handle this in backward-compatible fashion.