`(as-consensus-buff)` function for serializing values

[kantai]

We should support serializing Clarity value to their consensus serialization format, i.e., the serialization format committed to by the MARF (and miners) and used in the transaction wire format. The type signature of this function would be dependent on the input type (i.e., it would be a buffer of maximum length corresponding to the maximum serialized length of the input type).

Once implemented, we can also do away with hash function support for types other than buffs, because all types at that point will be easily convertible to buffs.

A related function is a (deser-consensus-buff (type-signature) (buff ...)) function ~though that would have a more complex type signature~ (edit: this actually has a much simpler type signature!)

[lgalabru]

What's our take on also introducing (as-buff) / (as-bytes)?

[kantai]

What's our take on also introducing (as-buff) / (as-bytes)?

What would be the difference between as-buff and as-consensus-buff? as-consensus-buff is bijective (i.e., any buffer generated by as-consensus-buff corresponds to exactly one Value), would as-buff not be bijective? Or is as-buff only defined for string types?

[lgalabru]

(as-buff ...) is not bijective, in my mind, it would be defined for anything that you could end up hashing in a smart contract: int/uint/string-ascii/string-utf8/principal.

[obycode]

I believe this can be closed with to-consensus-buff? and from-consensus-buff?, added in Clarity 2. @lgalabru if the as-buff idea is still useful, can you open that as a new issue?

[lgalabru]

My initial understanding of consensus-buff was incomplete / incorrect. consensus-buff is a superior approach and if developers want the inner data, they can strip the type prefix.