Modular Fork Configuration

[sebastianst]

Description

Whenever we add a new fork to the OP Stack, there are many places all over the monorepo where the new fork has to be added or adaptions have to be made (e.g. recent example: #13722). And the list of places is ever changing and growing. This is error prone and hard to maintain.

Hardforks can be dealt with in a more modular way, so that a new fork has to (ideally) be added to a single place and everything else just works automatically. Any remaining necessary adaptions are captured by automated failing tests.

In an exemplary way, modular fork handling was partially implemented for the op-chain-ops/genesis. UpgradeScheduleDeployConfig struct in #12506.

Before a proper design doc is written and approved, this issue is used to collect all those places that would benefit from a more modular way of handling forks.

Dump of non-modular places and todos

• move fork names and helpers into own package
• Finish Config.IsActivationBlock.
• actions/helpers/l2_sequencer.go ActBuildL2To(ForkName)
• op-e2e/actions/helpers/env.go SetupEnv fork selection
  - [ ] Lazy creation of fields as needed
• consolidate fork handling in op-e2e/actions/proofs/helpers/matrix.go with the new generic one in rollup.
• Holocene: initial op-node support for configurable eip-1559 params #12497 is a great resource for many manual places where forks have to be added
• op-e2e/e2eutils/setup.go
• op-e2e/actions/upgrades/helpers/config.go ApplyDeltaTimeOffset
• op-e2e/actions/helpers/user_test.go testCrossLayerUser
• holocene: load HoloceneTime from registry #12890
• same problem reemerges in the kurtosis package https://github.com/ethpandaops/optimism-package/pull/87/files
• https://github.com/ethereum-optimism/optimism/pull/13364/files#r1882855106 and other allocs init places
• op-node/rollup/sequencing/sequencer.go startBuildingBlock()