feat: Add parallel state root computation support for Bonsai trie

[matkt]

PR description

Description

This PR introduces parallel processing capabilities for Merkle Patricia Trie operations during state root computation in Bonsai storage format, significantly improving block validation performance.

Changes

Core Implementation

• ParallelStoredMerklePatriciaTrie: New parallel implementation of StoredMerklePatriciaTrie
  • Batches pending updates (puts/removes) before processing
  • Recursively processes branch children in parallel using ForkJoinPool
  • Handles branch, extension, leaf, and null node scenarios

Configuration

• WorldStateConfig: Added isParallelStateRootComputationEnabled flag (default: true)
• PathBasedExtraStorageConfiguration: Added parallel state root computation configuration
• CLI Option: --bonsai-parallel-state-root-computation-enabled to enable/disable feature

Key Features

1. Parallel Branch Processing: When a branch node has multiple children with updates, they are processed concurrently
2. Extension Node Expansion: Extensions are temporarily expanded into branches when beneficial for parallel processing
3. Leaf/Null Node Handling: Intelligent expansion into branch structures when multiple diverging updates exist
4. Smart Partitioning: Updates are grouped by size - large groups processed in parallel, small groups sequentially
5. Commit Cache: Thread-safe caching of node updates during parallel processing

Backward Compatibility

• Feature is opt-in via configuration flag (though enabled by default)
• Falls back to sequential StoredMerklePatriciaTrie when disabled
• No breaking changes to existing APIs
• Fully compatible with existing Bonsai storage format

Configuration Examples

# Enable (default)
besu --data-storage-format=BONSAI --bonsai-parallel-state-root-computation-enabled=true

# Disable for comparison/debugging
besu --data-storage-format=BONSAI --bonsai-parallel-state-root-computation-enabled=false

[ahamlat]

I suggest to use simple for loops to avoid steams overhead on memory allocations and latency.

[ahamlat]

Check this branch that has the change that replaces streams with simple for loops.

[ahamlat]

Suggested change

	final Bytes childLocation = Bytes.concatenate(location, Bytes.of(nibble));
	final byte[] out = new byte[pathDepth + 1];
	final byte[] in = location.toArrayUnsafe();
	System.arraycopy(in, 0, out, 0, pathDepth);
	out[len] = nibble;
	final Bytes childLocation = Bytes.wrap(out);

[ahamlat]

This the JMH benchmark that shows the different in performance. arraycopy_newArray_wrap is the new suggested implementation

Benchmark                                          (locationSize)  Mode  Cnt   Score   Error  Units
BytesConcatenateBenchmark.arraycopy_newArray_wrap               8  avgt   16   6.313 ± 0.321  ns/op
BytesConcatenateBenchmark.arraycopy_newArray_wrap              16  avgt   16   6.150 ± 0.140  ns/op
BytesConcatenateBenchmark.arraycopy_newArray_wrap              32  avgt   16   6.383 ± 0.291  ns/op
BytesConcatenateBenchmark.concat_bytesOf                        8  avgt   16  37.773 ± 6.029  ns/op
BytesConcatenateBenchmark.concat_bytesOf                       16  avgt   16  35.169 ± 2.331  ns/op
BytesConcatenateBenchmark.concat_bytesOf                       32  avgt   16  36.688 ± 1.568  ns/op

[ahamlat]

Check this branch with a clean implementation

[ahamlat]

The same as above, create a method that concatenates based on the underlying array.

[ahamlat]

The proposed changes can be addressed in a separate PR as this PR is about state root calculation.
For the instance type (8 Cores / 8 threads) we used in the screenshot below, it shows up to 40% improvement in block processing time. We've seeing less improvement on VMs with less cores (4 cores / 8 threads).