So far the interface to hz.erl is mostly unchanged, apart from prepare_aaci/1
Maybe prepare_aaci should be re-exported, but using it is exactly in line with the
'inconvenient but more flexible primitives' that hz_aaci.erl is meant to represent,
so, maybe that is a fine place to have to go for it, dunno.
This commit combines 13 separate commits:
add more atoms to AACI
serialize signatures
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
coerce stringy booleans
coerce bytes
coerce bits
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.
coerce character
It's really just an integer... Should we flatten it to an integer
instead? I don't know.
Also coerce unicode strings to FATE
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.
Coerce binaries as-is
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.
coerce hashes
It turns out there are a lot of types that, like option, should only be
valid as an opaque/normalized type, but should be substituted for
something different in the flat representation. If we restructure things
a little then we can implement all of these in one go.
Refactor type normalization
Some of these checks were redundant, and we probably don't actually need
substitution to wrap success/failure, since it isn't expected to fail
anyway... Now the logic is much simpler, and adding more built-in type
definitions should be easy.
Add a map for builtin types
This makes it much easier to implement all these standard library
things.
In doing so I changed the convention for option, hash, unit, to be
stringy rather than atoms.
Also I changed some error messages based on what was more helpful during
debugging of the unit tests.
Add more builtin types
We probably should extract these from the standard library instead of
cherry picking the ones that are needed by the chain? e.g. Chain.tx
still doesn't work.
remaining types
`tx` isn't defined in all the same places that pointee, name, base_tx,
fr, fp are defined, but actually it is the only one not in the list I
was looking at, so we are all good. As demonstration, there is also a
test case for Set.set, despite Set.set not being defined as a builtin
type.
