Use cbor-gen encoding for metadata instead of go-ipld-prime

[hannahhoward]

Goals

Use cbor-gen encoding for speed bump working with metadata structs

Implementation

Memory profiles indicate assembling Metadata IPLD structs to encode to bytes consumed significant memory in benchmarks:

Moreover, fuzz testing has found scenarios where this can be used to panic the decoder: LeastAuthority/go-ipld-prime#2

Switching to using cbor-gen encodings provides a significant performance benefit, and cbor-gen already has significant fuzz testing.

With the change (note almost 150MB less memory used in benchmark):

[rvagg]

@hannahhoward cbor-gen makes some strictness tradeoffs as part of its speed improvements; most notably it'll ignore trailing bytes after it's parsed the structures out that it expects. Within Filecoin, to deal with this there's an attempt to re-encode everything that comes from the outside (untrusted) to ensure that canonical forms of data structures. This is fine for use-cases, but opens security (or other) holes where canonicity matters and this isn't properly dealt with. Also cbor-gen doesn't do maps properly (according to dag-cbor and the CBOR spec). Maps are avoided in Filecoin alltogether, using tuples everywhere, and there was a proposal to remove that functionality entirely from cbor-gen so as not to provide a potentially confusing option. I've proposed at least fixing it (whyrusleeping/cbor-gen#42) but I don't see much appetite for tinkering with cbor-gen at this late stage (for Filecoin) so that's probably not going anywhere.

I don't know whether either of these things impact graphsync, you're in the best position to make that call. I just wanted to make sure you're aware and are comfortable with those tradeoffs.