feat(bindnode): support listpairs struct representation

[rvagg]

I want order-preserving structs without a pre-defined strict order (tuple), so this implements listpairs which is in the schema spec but has sparse support through go-ipld-prime.

type Blop struct {
  foo optional Int
  bar optional String
  baz optional String
} representation listpairs

type Blop struct {
  Foo *int
  Bar  *string
  Baz *string
}

[ "foo", 100, "baz", "bing" ]

(edit: actually should be this:)

[ [ "foo", 100 ], [ "baz", "bing" ] ]

But also this should decode to the same struct (see out-of-order test):

[ "baz", "bing", "foo", 100 ]

(edit: actually should be this:)

[ [ "baz", "bing" ], [ "foo", 100 ] ]

[willscott]

is this meant to have a comment?

[rvagg]

oh, embarrassing ... that's there cause I don't actually know why I would want to put the next line there; I intended to figure this out

[rvagg]

marked as draft cause I just realised after writing out the example above that listpairs is actually [[k1,v1],[k2,v2]], so a list of k/v tuples; so I need to update the repr to look like that!

[rvagg]

OK, fixed, this now handles [[k1,v1],[k2,v2]...]. It's required a bit more code because of the need for new intermediate assemblers for the inner lists that are strictly length of two, so we have _listpairsFieldAssemblerRepr and _listpairsFieldListAssemblerRepr to set that up properly.

I also extended the test a bit more so we're not just setting strings as values but also adding a recursive kind on one of the fields, so we end up doing a [["foo","0"],["bar","1"],["baz","2"],["qux",["3","4"]]] where the qux field is a list of strings.

[rvagg]

Made the parser handle "listpairs" for structs in the DSL, including enabling the test fixture that's been waiting to be implemented: ipld/ipld#281

[willscott]

🚀

[rvagg]

good thing I held off until I had a chance to properly try and use this, it borked on complex nested values—trying to do a listpairs within a listpairs errored out; very tricky to get the "level" right with these builders, representation builders use the schema builders but always need to force them to drop back down to representation level when returning sub-builders to the user

hopefully fixed now, still trying to put it to use