Zebra: Checksum(Read|Writ)er

[dconnolly]

Re: adc421f7fee6e14d54d233a08df259b234b1ca20:

Deserialization does an extra allocation, copying the body into a temporary buffer. This avoids two problems: 1) capping the number of bytes that can be read by the Reader passed into the body parser and 2) allows making two passes over the body data, one to parse it and one to compute the checksum.

We could avoid making two passes over the body by computing the checksum simultaneously with the parsing. A convenient way to do this would be to define a

struct ChecksumReader<R: Read> {
    inner: R,
    digest: Sha256,
}

impl<R: Read> Read for ChecksumReader<R> { /* ... */ }

and implement Read for ChecksumReader to forward reads from the inner reader, copying data into the digest object as it does so. (It could also have a maximum length to enforce that we do not read past the nominal end of the body).

A similar ChecksumWriter could be used during serialization, although because the checksum is at the beginning rather than the end of the message it does not help avoid an allocation there. It could also be generic over a Digest implementation, although because we need a truncated double-SHA256 we would have to write a custom Digest implementation, so this is probably not worthwhile unless we have other checksum types.

[hdevalence]

The first paragraph from that commit message seems like a separate atom than the ChecksumReader, so I cut it out into a separate, smaller issue.

[hdevalence]

Do we want to have a ChecksumWriter? It's nice for symmetry but because Bitcoin places the checksum in the header I don't think we can save any allocations anyways, so it might be simpler to stick with the current code that just does Sha256dChecksum::from(&body).

[hdevalence]

This might not be important any more because of #22, or might rather be subsumed by the optimizations mentioned in its comments.

[hdevalence]

Closing this because we don't currently need it now that we use a Tokio codec.