state of the world for this ADL

[mvdan]

The following is done:

• Creating new HAMTs with arbitrary parameters, or filecoin actors v3 parameters: Prototype, Builder, etc.
• Thanks to the above, we can decode existing HAMT blocks too.
• Using a HAMT in a read-only way, including following links.

The following are the major TODOs. The code has a few more inline TODOs, but they're mostly minor.

1. A good way to modify an existing HAMT.

Right now, the best way would be to set up a new builder, copy all previous key-values we want to keep, and add new key-values. This is inefficient, especially with large maps.

A better way, as discussed with @mikeal some time ago, would be to batch a series of map changes (sets, deletes, etc) and produce a single new HAMT node with those changes. For example, if 10 operations all require re-balancing the same bucket, we'd do all of those steps in memory and only produce a new IPLD node (and possibly new encoded blocks and CIDs) at the very end, reducing churn and cost.

Note that ipld-prime nodes are immutable by design. Once you have an ipld.Node value, it can't be modified in-place. So a "modify" API would take a HAMT node value and return a new one, even if a large portion of the tree is unmodified and reused as-is.

2. The Reify API; e.g. going from a data model HAMT node to the ADL node, assuming the same shape.

3. More practical testing against Filecoin HAMTs, as they are by far the HAMTs that we deal with the most.

Right now we just have one test, TestFilecoinBasic. More should be added to test more edge cases, and we should also try swapping out go-hamt-ipld for go-ipld-adl-hamt in one or two projects using Filecoin HAMTs directly. Ideally one of the projects that would benefit from ipld-prime the most, such as needing selectors.