ProgressiveMerkleHasher and progressive container support

[michaelsproul]

This PR contains all of the tree_hash changes required to support EIP-7916 and EIP-8016:

• ProgressiveMerkleHasher: an analog of MerkleHasher, it has a lazy API where it can ingest bytes and hash them incrementally. It uses a MerkleHasher under the hood to do the hashing of the binary subtrees.
• TreeHash implementation for Bitfield<Progressive> from ethereum_ssz.
• Derive macro support for struct_behaviour = "progressive_container". This generates code that uses a ProgressiveMerkleHasher for the fields. It comes with a new attribute active_fields({0,1},+) which is used to insert zero hashes for inactivated fields. The derive macro also generates a 32-byte array representing the active fields as a bitfield (at compile time), and generates code to mix this bitfield into the root, following the spec.
• Derive macro support for enum_behaviour = "compatible_union". Compatible unions behave quite similarly to the existing (and now deprecated) union type, with the difference being that their g-indices and merkle tree structure is stable across all enum variants. For now the macro does not verify that enum variants are compatible, because this verification is not mandatory (it is safe if the only compatible unions happen to be compatible, which the spec should ensure). Verification is left for a follow-up PR: Compatible union validation ethereum_ssz#72.
• As part of compatible union support, we add a new variant attribute tree_hash(selector = "1") which can set the selector for compatible unions only. To avoid duplication with ethereum_ssz this selector is read from the ssz attribute, or the tree_hash attribute (they must be consistent if both are set). See discussion: Progressive data structures and tests EIP-7916, EIP-8016 lighthouse#8505 (comment).

Depends on:

• Progressive bitlist and compatible union support EIP-7916, EIP-8016 ethereum_ssz#67

[macladson]

I'm going to work on flipping the tree structure to the new spec

[codecov]

Codecov Report

❌ Patch coverage is 94.54545% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.49%. Comparing base (adef128) to head (03d9fa4).

Files with missing lines	Patch %	Lines
tree_hash/src/progressive_merkle_hasher.rs	86.79%	7 Missing ⚠️
tree_hash/src/merkle_hasher.rs	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #43      +/-   ##
==========================================
+ Coverage   91.36%   92.49%   +1.13%     
==========================================
  Files           7        8       +1     
  Lines         463      626     +163     
==========================================
+ Hits          423      579     +156     
- Misses         40       47       +7     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[macladson]

I think this being a Vec here is probably pretty inefficient so when we are looking at doing optimizations later we should consider changing how we handle the buffer

[macladson]

This technically could overflow, we could use checked_mul instead and add a new error variant for the overflow, but practically the number of levels would you need to trigger this is enormous

[macladson]

This isn't really an issue but just noting that this will panic in cases where self.buffer.len() > BYTES_PER_CHUNK. This is guaranteed to be impossible since write will always return leaving buffer < BYTES_PER_CHUNK.