Hash-based integrity checking of operation sets

[ept]

At the moment, tesseract has no integrity checks. For example, a buggy node could send two different operations with the same sequence number to different peers, and they may never notice that they have diverged.

A simple approach for fixing this would be to take a leaf out of git's model: each operation has a cryptographic hash that covers the contents of the operation, the author, and the hashes of the prior operations on which it depends. The recipient must check that the hashes match up. Such hash-chaining alone is not sufficient to prevent disruption by actively malicious peers, but it would catch a lot of accidental bugs, and it would pave the way for a protocol that is robust against malicious peers (e.g. using digital signatures).

[ept]

Hash chaining of Automerge changes is implemented as part of the new binary format #253. Implications for networking layers are discussed in #290. I'm going to close this issue and leave further discussion on those issues.