**Current Problem**
When X transactions are created, with M transactions out of them having
`gasFeeCap` greater than the current `baseFeePerGas` for the block, and
N transactions having `gasFeeCap` lower, all X transactions get added to
the yellow pool (baseFee) in the txpool and they never get mined.
However when X transactions all having `gasFeeCap` higher than the
`baseFeePerGas` are created, they all get added to the green pool
(pending) in the txpool and thus get mined.
This phenomenon can be inspected in the
`signEIP1559TxsLowerAndHigherThanBaseFee2` function where the number of
transactions that should have `gasFeeCap` higher than and lower than the
current `baseFeePerGas` is specified in its parameter - `func
signEIP1559TxsLowerAndHigherThanBaseFee2(amountLower, amountHigher
int...`.
When `amountLower` is set as `0`, all transactions created from
`amountHigher` will be mined because they have `gasFeeCap` >
`baseFeePerGas`. When `amountLower` has a value > `0`, all the
transactions created (including transactions created with
`amountHigher`) will go to the yellow pool (baseFee) and thus do not get
mined.
To fix#6798
Follows the same pattern as other temporary fixes for BSC.
Tested locally and the transaction in question shows the same behaviour
as nethermind, coming to the same gas used and reverted behaviour by the
end. Tracing the block also works as expected now.
Tracing a transaction after the fork at 21735000 loads up the new
contract as expected as well.
Fees going to the gas fee recipient should be based on the actual gas
used (available in the receipt) rather than the gas limit in a
transaction. This fixes Hive test "GetPayloadV2 Block Value".
Also `engine_getPayloadBodiesByRangeV1` params should be encoded as hex
strings.
Solidity 0.8.0 breaks the current use of `payable` in these test
contracts, resulting in errors like
```
Error: Type address is not implicitly convertible to expected type address payable.
--> selfDestructor.sol:10:9:
|
10 | address payable nil = address(0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Related to #6680
In v2.36.0 we correctly trace this transaction, however due to a code
ordering issue in previous releases, there was an 'out of gas' response,
because we fell through to the code here where
ErrContractAddressCollision will be returned as such. This change isn't
the fix, but ensures the actual error is returned.
