A classic encoding of a merkle tree is to store the layers consecutively
in memory breadth-first. This encoding has several advantages:
* Good performance for accessing successive nodes, such as when
constructing the tree or serializing it
* Significantly lower memory usage - avoids the per-node allocation
overhead which otherwise more than doubles the memory usage for
"regular" 32-byte hashes
* Less memory management - a single memory allocation can reserve memory
for the whole tree meaning that there are fewer allocations to keep
track of
* Simplified buffer lifetimes - with all memory allocated up-front,
there's no need for cross-thread memory management or transfers
While we're here, we can clean up a few other things in the
implementation:
* Move async implementation to `merkletree` so that it doesn't have to
be repeated
* Factor tree construction into preparation and computation - the latter
is the part offloaded onto a different thread
* Simplify task posting - `threadpools` already creates a "task" from
the worker function call
* Deprecate several high-overhead accessors that presumably are only
needed in tests
For minimal correctness, we must ensure that buffers that cross the
thread boundary are allocated and deallocated within the same thread and
that there is no reference counting going on during the computation.
To get there with minimal changes:
* Preallocate a buffer for the outcome of the merkle tree computation
* Pass pointers instead of `ref` types between threads
* Avoid relying on isolation - this is an ORC-only feature
* Add `SharedBuf` as a simple "view" type that allows working with a set
of values while at the same time avoiding allocations and refcounts -
the view checks for out-of-bounds acccess much like a seq, but the user
is responsible for managing lifetime (which in this case is simple since
all that needs to happen is for the task to complete)
* In order not to upset the code too much, use a simple linear packer
for the hashes that simply copies the values back and forth
* Block cancellation and panic if the thread signalling mechanism fails
- cancelling the task itself would require inserting cancellation points
in the computation
The worker task relies on a nuance, namely that calling a closure
procedure does not count as a reference-counting event - while this
works, it can be brittle in "general" code since it's easy to make copy
of the closure itself by accident - the refactoring necessary for
addressing this point is beyond the scope of this change however.
