Update how transaction priority is affected by different factors

[shawntabrizi]

cc @tomusdrw

substrate/frame/system/src/lib.rs

Line 1483 in 71f57ea

priority: info.weight as TransactionPriority,

This SignedExtension is bumping the priority by weight
Which is sort of dumb, why would higher weight transaction have higher priority 🤔

maybe it pays more in fees, but since weight is a scarce block resource, we should rather prioritize transactions with fee per weight unit, not overall fee

In general, it does not seem that we correctly factor and scale the different runtime factors which can affect the transaction queue priority.

[tomusdrw]

Basically, since the end priority of a transaction is simply a sum of all priorities returned by individual SignedExtensions we should make sure to apply proper scaling factors to each of them. Currently we just add a bunch of numbers with different units together, namely:
weight (from CheckWeight) + weight (CheckNonce) + fee (Charge.Payment)

What's more, with Operational class we jump to max_value right away, which prevents any prioritisation within that class.

I think we should make sure that some sort of fee/weight metric has the most impact on priority.

The priority for unsigned transactions is also modified within pallet-local ValidateUnsigned implementations, which probably should be taken into account too.