GitLab

(This is a logical port of
https://github.com/ipld/go-ipld-prime/pull/169 to follow
https://github.com/ipld/go-ipld-prime/pull/172 .)

I've added more documentation -- particularly, cautionary notes on the
package-scope functions which read the global shared state.

The hope is that this might be helpful if you want to build a
multicodec registry other than the global one, but are still buying
into the idea of the registry being keyed by indicator numbers.

(I'm... not actually sure how useful this is, because I'd think if
you're building something other than the default, there's also a good
chance you'd want *more* features than a primitive numerical mapping,
which are probably going to be related to whatever your application
logic in the area is, and therefore not possible for this library
to usefully anticipate.  But, I dunno.  I'm doing this because
people are proposing attaching more features to the global, and
I'm not comfortable with it, and I'm hoping this will provide a
pressure release valve.)

The current interfaces are functionally unchanged.

The multicodec.Registry type can now be used when constructing
a cidlink.LinkSystem.  (This saves you from having to write the
glue functions to unbox cidlink and then do the LookupEncoder
and LookupDecode calls.)

For where this relates to LinkSystem, I considered a mechanism like:
`func (r *Registry) InstallOn(lsys *ipld.LinkSystem)` ...
and probably would've found that a bit cleaner.
However, it doesn't jive with the way we've isolated the CID types
into a package with a LinkSystem just for them (sigh; that really is
the gift of complexity that just keeps giving); you can see how the
EncoderChooser and DecoderChooser funcs need a tiny bit of type
assertions in order to figure out how to extract the multicodec
indicator from the Link/LinkPrototype types?  That bit is a bit
that we still want to keep cordoned off the rest of the import tree.

DefaultRegistry is also now an exported variable, in addition to the
functions which already worked with the global data.
I probably would've preferred to keep the DefaultRegistry variable
unexported, because I can't imagine any good coming of touching it,
but the relationship to LinkSystem detailed in the above paragraph
requires some access to it.