Persist fork-choice state > start from head

[dapplion]

Currently Lodestar follow the simpler strategy (1) on start-up to just consider the latest finalized state as the head. Then sync all blocks from finalized state to head from our peers, and re-populate fork-choice graph.

Another strategy (2) is to persist the fork-choice state (on shutdown and / or periodically) and restore that state on startup. This approach will prevent "reverting" the head to a much older state. This caused:

• Error pushing notifyForkchoiceUpdate (kintsugi-lodestar-besu) #3647
• Investigate: Startup behaviour of other CL clients especially in a post-merge world #3717

TODO:

• Research what each other client is doing
• Estimate the positives of strategy (2) vs (1), specially in periods of long non-finality
• Estimate the complexity of strategy (2) vs (1), and the cost of persisting this data + pruning.

Only if it's clear that positives >> complexity + cost, consider implementing.

[g11tech]

my 2 cents: I actually like that we got, helps us recover lots of random scenarios by restarting, especially where local EL can be buggy in post-merge world by having this easy option to step back.

[wemeetagain]

👍 We should make sure this feature has an enable/disable flag