In Geth chain-mode, logic to accept/reject transactions based on gas price/limit should match Geth

[MicaiahReid]

If a transaction gets into the miner's runTx function, and it fails in the VM, that catch block should probably add the transaction back into the pool.

Check against geth if:

1. a transaction like this: {"from" : "0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1", "gas": "0x5b8d80", "maxFeePerGas": "0x1" } (too low maxFeePerGas) immediately returns an error like this VM Exception while processing transaction: Transaction's maxFeePerGas (1) is less than the block's baseFeePerGas, and if
2. the transaction is then available in txpool_content

[jeffsmale90]

To paraphrase @MicaiahReid: "The best course of action is to add our check in the transaction-pool.ts prepareTransaction function to validate that a transaction's maxFeePerGas >= baseFeePerGas, and we'll do the rest in #2831"

For reference, the same behaviour is described in Geth here: https://github.com/ethereum/go-ethereum/blob/06540146524222f648d8b19c5bcb00a8fd3dd339/core/state_transition.go#L235

[jeffsmale90]

As per comment from the geth team here: ethereum/go-ethereum#24661 (comment), and @MicaiahReid 's (excellent) summary here: #2840 (review), Geth's behaviour is:

Gas Limit	Gas Price	Result	Notes
Unspecified	Unspecified	No error	Geth chooses a good gas price, then uses that price to estimate gas limit.
Specified	< baseFeePerGas	No error	Geth blindly accepts the gas price because the transaction has a gas limit.
Unspecified	< baseFeePerGas	Error: maxFeePerGas is less than block base fee.	Because no gas limit was specified, Geth needs to estimate it. To estimate it, it runs the transaction against the next block. Because the gas price is too low, it's rejected.

(Quoting @MicaiahReid)
The key difference between us and Geth in this case is that our eth_estimateGas function does not enforce a baseFeePerGas. This can be seen when we make the RuntimeBlock in eth_estimateGas:

const block = new RuntimeBlock(
  Quantity.from((parentHeader.number.toBigInt() || 0n) + 1n),
  parentHeader.parentHash,
  parentHeader.miner,
  tx.gas.toBuffer(),
  parentHeader.gasUsed.toBuffer(),
  parentHeader.timestamp,
  options.miner.difficulty,
  parentHeader.totalDifficulty,
  0n // no baseFeePerGas for estimates
);

So rather than this current change, we may just want to pass in the next block's baseFeePerGas rather than 0n.