Variable tip (auction) signed extension

[tomusdrw]

To address a prioritisation issues in case of congested chains, we might want the tip to be dynamic instead of static, so that when the time passes the user is willing to pay more tip to get the transaction included.

Original proposal by @jakoblell

Maybe we can find a better solution by changing substrate so that you can submit a transaction with a variable tip. This could work like the following:

Transaction executed before block number X: tip=0
Transaction executed from block number X+1 to Y: tip = (block_number - X) * tip_increment
Transaction executed after block number Y: tip = (Y - X) * tip_increment

That way the tip (and therefore the priority) of transactions will raise automatically if the chain is congested (up to a limit defined by the caller). It basically works like an auction and the first block producer willing to include the transaction for a given tip will win. This allows submitting transactions with the maximum tip you want to pay while still only paying as much tip as necessary. Having a mechanism like that will make it a lot easier for automated tools (like this relayer) to protect against DoS via tipping when submitting transactions in an automated way. It will also improve usability for human users (since you can just specify the maximum tip you are willing to pay and then let the blockchain decide how much tip is actually needed).

Implementing this will require adding the parameters X, Y and tip_increment to ChargeTransactionPayment (or creating an alternative SignedPayload to be used instead of ChargeTransactionPayment for adaptive tips).

Note that while this seems like a simple runtime change, it does require changes in the transaction pool implementation as well. The transaction pool does not query the runtime every time, but rather assumes the validity values are "static" for some time, or rather they can change according to some pre-defined rules (only for required/provides now, the rest is assumed to be static for the lifetime of transaction).
I think ideally we would change the priority field of ValidTransaction to explicitly state that the priority is dynamic and maybe even expose the entire calculation there (i.e. the pool would be able to compute current priority based on block difference).

[bkchr]

As a note: This will also increase the size of a tx.