Sophia accepts both sg_... and #... as signatures, so we should probably
accept binaries as signatures directly. People might expect to be able
to put the listy string "#..." in too, but that is more complex to do.
This is mainly so that gajudesk can pass text box content to hz as-is,
but also allows users to pass utf8 binaries in, if they want to, for
some reason.
The thing to remember about bits is that they are actually integers...
It is tempting to present bits as binaries, but that hides the nuance of
the infinite leading zeroes, the potential for infinite leading ones,
etc.
This took a surprising number of goose chases to work out... I had to
find out
- what is the gmser prefix for a signature (sg_)
- what is the gmb wrapper for a signature (none)
- what errors gmser can report when a signature is invalid
- what an example of a valid signature is
- what that example signature serializes to
A lot of this complexity was a consequence of trying to avoid redundant
extraction of the namespace's/contract's name, so on the other hand
letting it be redundant made all of the complexity kind of evaporate.
Add to that that we're now building a little deep list and then
flattening it, and this logic was able to get really neat in a way that
I couldn't work out a year ago.
Now we convert the ACI into trees of opaque types, then flatten the tree
into a map and a list of function specs, and only then dereference the
types in the function specs down to our accelerated annotated types.
Variants were working by accident, since
{variant, [{"VariantName", [Element]}]} had a similar enough form to
the opaque types that would come from something like
`type1(type2(int))`, but records were not working, since they have a
different form. Now both are handled explicitly so that only the
intended forms of each are handled.