Proposal: StreamMultihasher interface

Rational

Current MultihashHasher API is really simple and a great fit for most cases, however it has certain drawbacks that make it a bad fit for more low-level use cases.

1. API returns a Digest view for which you always have to allocate a buffer. If you have destination buffer for the multihash like a CAR or even a CID it creates unnecessary overhead of first allocating then copying the bytes into your destination.
   • It is also worth calling out that web crypto APIs require you to pass a ArrayBufferView.
2. API assumes that you can hold complete payload in memory. When working on a large payloads this becomes a real problem. Unfortunately currently browsers do not provide streaming crypto APIs, but there seems to be some proposals to address this, never the less it would still be good to have it in node and non web native implementations.
3. Sometimes you need a digest without the multiformat prefix and addressing above two without a way to omit the prefix would defeat the purpose in those instances.

Proposal

I end up defining separate interface to address above limitations and implemented two hashers that makes use of it

1. blake3 hasher
2. fr32-sha2-256-trunc254-padded-binary-tree hasher

I propose we uplift interface used by those implementations, possibly after iterating on it a bit here. I'm happy to update those implementations to align with interface that gets merged here.

Start by reviewing the current MultihashHasher API, then compare the proposed interface with the blake3-multihash implementation in src/lib.js and the referenced data-segment pull request. Done means reaching agreement on an uplifted streaming hasher interface that addresses buffer destinations, streaming payloads, and optional multiformat prefixes.