EIP-1559 tx pool support

[lightclient]

Note: the consensus-only changes are tracked in #22617

The main goal of the tx pool is to decentralize the submission of transactions to the network, it's absence would lead to the centralization of hash power since users would need to communicate their transactions directly with miners. Minority miners would be left out of the majority of transaction transmissions, since users would just broadcast their txs to the major mining pools.

Building a tx pool is easy--building a good one is more challenging. A naive implementation could relay everything it sees. This is clearly susceptible to a number of denial-of-service attacks. To do better, we should think of the tx pool as a rate limiter.

A robust tx pool should only share valid transactions with its peers that have the potential to be included in the near future. Today, clients achieve this by validating incoming transactions. They verify the static aspect of the transaction first and then they verify the contextual validity -- e.g. the transaction's gas price is greater than the client's minimum and is greater than the current lowest paying transaction in the pool.

Gas price is a nice single-dimension quantity that clients can use for contextual validity. EIP-1559 complicates this by introducing two dimensions that a transaction's price to be weighed against. The first is the transaction tip (aka priority fee, miner bribe, etc), the second is the fee cap. The tip refers to the max amount the transaction pays out directly to the miner of the block, while the fee cap refers to the max base fee a transaction is valid under.

The likelihood of a high fee cap transaction being mined in the near future with EIP-1559 is comparable to the likelihood of mining a high gas price transaction in the near future. This makes fee cap a good candidate [1] to replace gas price as the contextual validity check, and therefore in this PR we sort the pool by fee cap. If the pool fills up, we can drop transactions with the smallest fee cap first.

This presents a bit of a danger though -- if the pool is full transactions that have high tips, a high fee cap low tip transaction could displace a high tip transaction. If the high tip transaction had a reasonable fee cap, this would be probably be the wrong behaviour since both transactions could have roughly equal chances of being included, but one is much more lucrative for miners. Realistically, this scenario should almost never happen. Because the chain is expected to be in a steady-state with the base fee oscillating around the gas target, there should only be around a block or twos worth of executable transactions in the tx pool. Therefore, under normal conditions, it will be impossible for an objectively worse transaction to displace a better one.

This result allows use to naively use fee cap as the sole ordering mechanism in the tx pool. In cases where fee cap's are equal, it makes sense to use the tip as tie breaker. This brings us to the implementation of this PR. The following has been implemented:

• sort transactions by fee cap in a min heap, so the minimum value can be found and removed efficiently
• enforce configurable minimum tip (same as min gas price setting)
• either the fee cap or tip must be bumped more than the price bump percentage
• test tx pool set gas price (now min tip)
• test tx pool global limits
• test tx replacement mechanics

[MariusVanDerWijden]

I think it's easier to set this explicitly

Suggested change

	pool.currentMaxGas *= params.ElasticityMultiplier
	pool.currentMaxGas = newHead.GasLimit * params.ElasticityMultiplier

[lightclient]

I ended up updating the logic to require both feeCap and tip be updated to replace a tx. I think it may be an attack vector otherwise, because you can keep bumping the fee cap infinitely without any real repercussion.

[fjl]

Superseded by #22898