Design spike: proposal general hard fork solution compatible with silkworm

[arhag]

We need to maintain our own linear version of hard fork changes to the EOS EVM separate from the hard fork schedule of Ethereum. These hard forks may incorporate the changes of Ethereum hard forks, but they may also be introducing our own necessary changes that are considering hard forks.

We want this framework to not commit into source any particular block heights at which the hard fork should be activated on any particular network. Instead, the activation signal should come from the EOS EVM Contract and be relayed via SHiP to eos-evm-node so that it knows when to activate a particular version of the hard fork.

I think the protocol version number (which can be a single whole number) should just always be committed as part of the action return value of the pushtx action. Then eos-evm-node can detect when the version number advances on the first pushtx of a new virtual block and consider that block height of the virtual block (whatever it may be) to the block in which the hard fork was activated. The protocol version number should ideally be committed into each block somehow (perhaps in the nonce?) so that a node replaying the virtual blockchain could determine when it should activate hard forks without needing to refer back to the original source from the EOS blockchain.

This design spike should propose a solution to this problem not just at a high-level but it should also propose how the silkworm code could be modified in a minimal way to support this while trying to minimize merge conflicts with later upstream silkworm changes.