BAL-based perfect parallelization of transaction execution

[mirgee]

Adds --Xbal-perfect-parallelization-enabled config flag, enabled by default, which activates BAL-based perfect parallelization of transaction execution.

Adds a new interface, ParallelBlockTransactionProcessor, implemented by ParallelizedConcurrentTransactionProcessor (optimistic parallelization) and BalConcurrentTransactionProcessor (BAL-based parallelization), and used by ParallelTransactionPreprocessing to launch parallel block (pre)processing, which returns PreprocessingContext (unified for both processing types) currently containing only reference to the ParallelBlockTransactionProcessor used to obtain the transaction processing results later.

BalConcurrentTransactionProcessor launches and manages the futures processing individual transactions in the background. At the beginning of transaction processing, the prestate is loaded by applying corresponding state changes from the BAL. When the transaction processing result is ready, the state changes are imported to the block's accumulator in the main thread. Some categories of (pre)processing failures result in fallback to sequential processing.

The AbstractBlockProcessor trusts that the presence of absence of BALs in the block's body was validated before processBlock was called, and then uses the BALs if they are present, and, based on configuration, falls back to optimistic parallel or sequential processing. This is because the block may still be valid even if BALs are active and BAL is missing from the block body, e.g. in case of replaying a block older than BAL retention period.

These changes were tested by running a local devnet with spamoor and tx_fuzz, and it was verified all transactions are executed in parallel without conflicts.

An optional fail-fast transaction-wise validation of PartialBlockAccessListViews from TransactionProcessingResults against the blocks BlockAccessList (validating execution matches BAL) will be added separately, as well as BAL-based batch read prefetching.

Resolves #9079 .

[matkt]

really like the new implementation

[matkt]

LGTM, if we can just add tests for BALL //. I will run some nodes on mainnet with this PR to be sure we don't have any regression in the // part

[ahamlat]

Java arrays are not thread safe. I would suggest using a ConcurrentHashMap with an Integer as an index.

[matkt]

This isn't a problem because we change each index separately. That's already how it's done in the current code. We'll never have the same index modified by multiple parts of the code.

[ahamlat]

I think we should change it. Using a data structure that is not thread safe in a multi threaded environment can lead to inconsistent behaviour.

[matkt]

I think adding synchronization where it's not necessary might impact performance. maybe not too much. It's not necessarily within the scope of this PR, but if Mirgee wants to change it, I'm not against it.

[ahamlat]

A ConcurrentHashMap does introduce some synchronization, but with fine-grained locking and reads are lock-free. The array can explain some of the edge cases where we still have errors on parallel transaction processing.

[mirgee]

It is true that this would be a problem if multiple threads were modifying the array simultaneously, but in this case the array is always accessed exclusively by the main thread, so I don't see the need to use a synchronized data structure.

[matkt]

LGTM