Support Re-Executing Chain History in Parallel using Sub-Ranges

[aaronbuchwald]

Re-executing the full chain history currently requires, well, executing the full chain history. Unfortunately, that takes a very long time (several days to weeks depending on configuration).

Re-executing the chain history can provide both performance insights over the full chain history and test to ensure that as new changes are made the VM is still able to re-process the full chain history correctly.

Typically, we'd re-execute the chain history by bootstrapping a new node, but we could alternatively parallelize re-execution if we provide checkpoints of the state, so we can re-execute multiple sub-ranges of the chain history and execute the full chain history across all of them.

In other words, we can archive snapshots of the state at multiple checkpoints ie. 5m, 10m, etc. and then spin up multiple runners to execute the all of the sub-ranges [0, 5m], [5m, 10m], etc.

This could provide much faster feedback (hours or days depending on how much we parallelize) than simply re-executing the full chain history or bootstrapping a new node with state sync disabled.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.