Refactor miner/dBFT to properly support post-merge behaviour

[qianhh]

Rationale

During v1.14, Ethereum perform “The Merge” to split the original Geth into two parts, a Consensus Layer (CL) and an Execution Layer (EL). Since then, the Geth removed its functionality in PoW/PoA maintenance step by step. Instead, it needs a connection to CL to download new blocks, and the Geth client itself works more like a decentralized database without any possibility of inconsistency.

In v1.14, they implemented the following things and performed “The Merge”.

1. Add configurations about TerminalTotalDifficulty and MergeNetsplitBlock to switch from PoW to PoS block handling;
2. Implement eth/catalyst for eth1/eth2 RPC integration;
3. Disable the automatic block sealing of internal miner worker;
4. Separate the blob data storage and pruning to CL.

After the Merge, they implemented the following things to simplify block handling.

1. Remove reorg handling in local chain data maintenance, as well as the total difficulty data from database;
2. Simplify the check of PoW/PoS switch;
3. Remove the block mining broadcast and total difficulty information from network protocol;
4. Support pruned-able chain data and cutoff operations with configurable checkpoints.

Now in v1.16, they implemented the following things to reduce EL resource usage.

1. Use ETH69 range packets instead of ETH67/ETH68 single block packets to simplify network communication.

Implementation

Ref: #487 (comment).

We need to refactor miner/dBFT to properly support post-merge behaviour, otherwise we have to face a road division from Geth upstream, their new features are becoming more unsuitable in our use case (a pre-merge blockchain).

1940bd3 uses dBFT as the CL to receive finialized block information, but maybe no enough.

[txhsl]

#520