parallelize sender recovery from transactions + performance tests

[haardikk21]

When a new flashblock comes in, we spend a decent amount of time iterating through the new transactions to perform sender recovery. For older flashblocks we have this information cached in the in-memory state but the new transaction sender recovery still takes a reasonable amount of time (~10-15% of flashblock processing time based on last manual test)

We do so sequentially for each transaction following upstream Reth's behaviour. The reth team recently made a PR expected to be included in the next release of reth that parallelizes sender recovery which led to some performance gains.

We may be able to benefit from something similar ourselves. Reth PR Here: paradigmxyz/reth#20169. The exact approach may not work for us but generally the idea of parallelized sender recovery should overall still be able to help out

My suggested approach to doing this:

• Add a performance test where we create a few flashblocks with 30-40 transactions each from a varying set of senders
• Figure out how much time is spent doing sender recovery within the flashblock processing pipeline, both as an absolute measure and as a percentage of overall flashblock processing time
• Switch to parallel sender recovery
• Cross-compare the results

if the results look good, we can make this the default method

[garik100]

Initial project setup and documentation