feat(protocol): Calculate fee/reward based on proof time w/ 1559 math

[adaki2004]

Proposer fee /prover reward balanced algorithm

This PR introduces an implementation of the proposer fee / prover reward equilibrium calculation, aiming to balance deposits and withdrawals. The implemented (new baseFeeProof) calculation depends on the proving time and utilizes the following parameters:

proofTimeTarget: A preset of the average proving time (shall be overestimated-> cause no harm)
gasConsumed: The consumed L2 gas per block (currently set to the gasLimit).
adjustmentQuotient: The quotient used for adjusting base fees (16).

The base fee proof serves as a dynamic fee that adapts to the network conditions, aiming to keep the inflow and outflow of tokens in balance.

See issue discussion:
https://github.com/taikoxyz/internal/issues/121
(Especially see Brecht's comment here, with fixed proof time target (Target 1) and 'Mint new tokens when needed' approach - in reality the deposits and withdrawals will be balanced.)

This is an experiment where the base idea is to have a simplified fee / reward calculation structure with TKO for provers and proposers and depends on proving time.

Notes:

• If targetProofTime is far (above) from the actual proof time, the system will need more time to reach equilibrium when the time starts stabilizing - (and need to be stabilized below this target
• If proof time is very stable but a tiny bit above average, it will increase the baseFeeProof ( see foundry test test_reward_and_fee_if_proof_time_stable_but_above_time_target) -> Setting the targetProofTime above the actual edge (where we expect the proof times) does not harm at all, because if proof times are below that, the equilibrium will be reached (deposits ≈ withdrawals) anyhow at some point.

What remains to be done in this PR:

• Implement pooling mechanism to distribute rewards based on deposits - in case mintAllowed = false
• Implement test cases when mintAllowed = false
• rebase (lots of merge conflicts with the base L2_1559_rebase)
• address failing HH / Typescript tests (and other interface changes)
• search for more gas optimization

[adaki2004]

@dantaik @Brechtpd

We definitely need to be reasonable with the proofTimeTarget.

• Better to overestimate a little bit than under. Overestimating might cause fee decreasing, which net good, if not profitable, provers simply refuse to provide proofs within that time (Question if this concern is applicable on testnet..?) 
If we underestimate and provers are technically not able to be within the window the fee will be ever-increasing, so that is the worst case.


How to test possible main net scenario ?

Remove the ‘x’ prefix from the function names of the TaikoL1LibTokenomicsMainnet.t.sol and use gas setting: 3000M in foundry.toml ->
- Currently these tests shall be run locally, but simulates a kind of mainnet scenario where the first 30 minutes there will be some blocks being proposed (not proved) then proving starts.
- If this gas setting is enabled to run simulation, the anchor tests will fails, because of baseFee mismatch (!!)

[davidtaikocha]

seems that there is a chance that when there are more and more unproven blocks on chain, reward will be less and less? or i missed something?

[adaki2004]

Theoretically possible, in case proposers stop proposing.
The fee connected with the proof time issued seconds, so the more 'unproven' (while still being proposed) -> the more the fee -> the bigger the reward pool.

[dantaik]

@adaki2004 please also fix all the warnings except those related to block.prevrandao.