core: post-Amsterdam, don't subtract tx gas limit from GasPool before starting execution

[jwasinger]

It fixes the failing block_2d_gas_boundary_exact_fit.json cases when I run with go test.

It feels like the concept of the gas pool as it exists now has some friction with 8037. Instead of "take gas from the pool, execute a transaction, return the remaining gas to the pool", it's now "execute a transaction, see if the gas used allows it to fit into the block, and then accumulate the total gas used in both dimensions etc".

[MariusVanDerWijden]

I don't think this is correct in principle tbh. We might want to change the test case instead

[jwasinger]

I think it is correct, although it's confusing. We've changed the tx validity condition in 8037 s.t. we no longer require the entire gas limit of the transaction to be covered by the remaining gas in the block. Now, we have to execute the tx and determine the tx contribution towards block fullness by its gas used vector and the contribution to the bottleneck resource.

[jwasinger]

One way we could keep the existing gas pool somewhat more intact is to add a rule to 8037 that in order to include a tx in a block, assert tx.gas_limit <= block.gas_limit - max(cumulative_regular_gas_used, cumulative_state_gas_used).