Rework Transaction Priority calculation

[tomusdrw]

Closes #5672
Closes #9317

Alternative take on #9596
(we can leave the adjuster from previous PR, but I don't think it is going to be useful at all, given no extensions change priority).

This PR changes the way Transaction Priority is calculated by following SignedExtensions:

1. CheckWeight
2. ChargeTransactionPayment

For CheckWeight it removes the priority calculation completely, leaving the priority as 0 for all dispatch classes. Please note that this might cause a bit of an havoc on existing chains without any extra signed extension that would alter priority (which is discouraged anyway) - all transactions would end up having the same priority (0) and the inclusion might be done at random (i.e. depending on the transaction pool ordering - currently based on the insertion time), note that the requirements (i.e. nonce) would still be respected though.

ChargeTransactionPayment is completely reworked and is now a single place responsible for calculating the overall priority (all other SignedExtensions in this repo do not alter it).
The priority depends on the dispatch class and the amount of tip-per-weight or tip-per-length (whatever is more limiting) the sender is willing to pay.
Transactions without a tip are using a minimal tip value of 1 for priority calculations to make sure we don't end up with all transactions with 0 priority. The consequence of this is that "smaller" transactions are more preferred than the "large" ones (note the behavior used to be similar with CheckWeight's prioriy).

Operational transactions are getting additional priority bump - not as high as previously (3/4 * u64::max), because that prevents other transactions from getting in front of them in the pool, but now equal to the OperationalVirtualTip amount configurable by a rutnime developer.

Companion PR: paritytech/polkadot#3901

[apopiak]

The PR seems fine. The prioritization makes sense.
I'm just worried that this will have weird unintended consequences for downstream chains using it.
Any way we can mitigate that? Any tests we could run to see whether the behavior is sane? Could we run a few validator nodes of e.g. Kusama with this changed priority? (I know that these are runtime-level changes and thus hard to test with a canary node.)

[tomusdrw]

@apopiak Please take a look once again, I've reworked the calculation after audit feedback.

I'm just worried that this will have weird unintended consequences for downstream chains using it.

This is a runtime change, so it will be intentional to upgrade to a new version. Note that CheckWeight extension was never sufficient to run a secure chain (actually it was even harmful), so I'm not sure if there is much more we can do than clearly state that in the release notes.

Any tests we could run to see whether the behavior is sane? Could we run a few validator nodes of e.g. Kusama with this changed priority?

We would need to define "sane" first :) Block authors are free to put transactions into blocks in whatever order they want, the priority is just helping them to maximize their outcomes. We have tests and audits to ensure QA and I'd argue that this change is strictly better than what we have currently deployed (mutliple extensions contributing to priority with incorrect orders of magnitude, hence preventing proper tip usage).

[gww-parity]

What about adding some assert in a code to ensure assumptions? (i.e. that values are in expected ranges, preventing saturation)

[tomusdrw]

bot merge

[ghost]

Trying merge.