Re-Prioritize pool transactions by effective gas price

[JoshOrndorff]

This PR is a stop-gap measure that allows ethereum transactions to be properly prioritized by gas_price and also properly prioritized alongside non-ethereum transactions that specify a flat tip amount rather than a gas price.

It makes two concrete changes to our transaction prioritization:

1. It stops adding-weight-based fees to all transactions and relies only on those set by pallet-transaction-payment. This is based on Allow adjusting priority coming from Signed Extensions paritytech/substrate#9596 which is not yet merged in Substrate, but is on our pinned Substrate branch. (notice the changes to Cargo.lock.)
2. It overwrites the priorities assigned by pallet_transaction_payment with "effective gas prices" calculated from our GasWeightMapping.

The latter is a bit of a stop-gap measure. A more complete ethereum-first approach would be to replace pallet-transaction-payment with a new pallet that allows users to specify gas price for all transactions including "normal" frame transactions.

This stopgap approach was also explored briefly in the Frontier repo in polkadot-evm/frontier#378.

[notlesh]

Interesting idea. Keep in mind that EIP-1559 will make Ethereum's gas structure look more like Substrate's pallet-transaction-payment, although if we adopt it we will probably want backwards-compatibility (as Ethereum will do).

[notlesh]

👀

[JoshOrndorff]

Yeah, this is ugly. I think the more thorough approach would be to have a pallet-ethereum-transaction-payment that properly handles fees in a Frontier-equipped chain. This is a stop-gap measure.

[JoshOrndorff]

This will make sense again in conjunction with paritytech/substrate#9596

EDIT: That is not merge in Substrate yet, so I've put it on our pinned Susbtrate fork. See moonbeam-foundation/substrate@2af6e2c

[JoshOrndorff]

So the test failure here is legit. It happens with the call to sudo_unchecked_weight when the weight is set too low. I see where a weight set to zero would cause a division by zero, but I didn't expect it to happen for low-but-non-zero weights. The call that exists in our test has a weight of 1. By experimenting manually, I've found that a weight of 20_000 is low enough that the test fails, but a weight of 30_000 is high enough that it passes.