Encode integrity check as multihash

[singpolyma]

Using a byte string with internal label as much more compact than
storing base16 as unicode. Re-using the multihash spec so we don't have
to invent our own but using such a small subset of it that implementors
do not need to be familiar with multihash at all to implement this.

This change does not affect semantic hashes, since semantic hashes are
computed on fully resolved expressions.

Closes #548

[Gabriella439]

I think this mainly needs an encoding test, but otherwise looks great to me

[Nadrieril]

I am weakly opposed to this, since this will require special support for the cbor library used by each implementation. Moreover we rarely encode non-resolved expressions, so the gains look small to me.
The Rust cbor library for example essentially only supports encoding a JSON value. I expect that in languages with built-in JSON-like structures, like JavaScript, cbor libraries could have similar limitations.

[singpolyma]

I am weakly opposed to this, since this will require special support for the cbor library used by each implementation

What kind of "special support" do you mean? This only uses one of the CBOR "major types", the most fundamental building blocks of CBOR, and one Dhall already relies on for bignums.

[f-f]

I am also not feeling great about this, for the same reasons as @Nadrieril:

• some CBOR libraries don't easily give access to the "building blocks" of CBOR and basically only support encoding a JSON value (the Clojure one doesn't even mention "multihash")
• the gains are little (as encoding non-resolved expressions is rare indeed) compared to the implementation complications this adds

[singpolyma]

 doesn't even mention "multihash"

multihash has nothing to do with CBOR and if that's adding confusion we can remove mention of it from the spec entirely. This change only moves from a CBOR array of two CBOR unicode strings to a single CBOR bytestring.

[singpolyma]

some CBOR libraries don't easily give access to the "building blocks" of CBOR and basically only support encoding a JSON value (the [Clojure one](https://github.com/greglook/clj-cbor)

Reading the source there it looks like byestrings are mapped to https://clojuredocs.org/clojure.core/bytes I will look at rust and (since it came up) javascript CBOR libraries soon for this feature also.

[singpolyma]

browser side CBOR library for JavaScript supports bytestring as Uint8Array: https://github.com/paroga/cbor-js/blob/master/cbor.js#L158

Rust serde_cbor implements for at least &[u8]: https://docs.rs/serde/1.0.91/src/serde/de/impls.rs.html#486-493 + https://docs.rs/serde_cbor/0.9.0/src/serde_cbor/de.rs.html#183

[Gabriella439]

So from reading through this it seems like the only sticky issue is the Clojure clj-cbor library.

@f-f: Would it be possible to open an issue against them to support encoding Clojure byte arrays as CBOR byte arrays?

For me it seems reasonable to expect a language to (A) support byte arrays and (B) have a CBOR library that supports encoding those byte arrays as CBOR byte arrays.

[f-f]

@Gabriel439 sorry for the delay on this. As @singpolyma figured I was just confused by the mention of "multihash" (which is independent from the CBOR encoding, while I thought it was a CBOR feature).
Anyways as he noted clj-cbor seems to encode Java ByteArrays to CBOR bytestrings, so everything should be fine library-wise. Thanks for looking into this!

[singpolyma]

I've pushed updates to the tests based on my branch implementation in dhall-ruby