Improve async message fee system

[AurelienFT]

Asynchronous message fee improvements proposal

Introduction

Massa provides a method for calling a function of a smart contract in the future.
This can be triggered using an ABI called send_message. The ABI takes as parameters the function to be called, along with its parameters, trigger conditions, and coins. It also requires a range of slots for the message to be executed, as well as a fee.
The fee is utilized to prioritize asynchronous messages. Messages are executed within each slot to prevent excessive computational usage; thus, a gas system is implemented along with fees for prioritization.
This mechanism operates similarly to the operation pool, with the key distinction being its determinism. Determinism is ensured by allowing the addition of new messages to the pool solely through smart contract execution and all nodes across the network execute the same operations.

Problem

Like in a operation pool, it's possible for someone to spam the asynchronous pool to fill the slots for free as soon as the fee to be executed in a slot is 0 and so force the rest of the network to pay fees.
The problem with the asynchronous pool is that your message has been sent long time ago with a predefined 0 as fee and so if someone take all the space your message will never be executed in its range of slots.
The problem is the same if the network is congested and the pool fees are growing slot by slot : the fee you place 1 year ago might not be enough now and so your message will not be executed without your SC to be noticed.
This can be very critical for a lot of applications for examples the ones that rely on a loop that is created by a chain of asynchronous message that could be broke.

Proposition

This proposition proposes a solution to this problem by allowing to increase the fee placed in a asynchronous message in the pool.
The first part of this solution is to give possibility for the message to have a range of fee. The coins related to the range of fee will be locked and when the message is executed only the minimum needed will be gathered from the locked coins to be burned (this requires to change the current behaviour that burns directly the fees), the rest will be given back to the address.

Even though this mechanism allow more flexibility with the fees and can prevents little changes in the fee market to be absorbed this doesn't seems suitable for big market fees changes and for large smart contract with a lot of asynchronous messages that would lead to an enormous amount of coins locked.

A second mechanism can be added to increase the fee in an asynchronous message. To increase the fee in a deterministic way, this need to be done using an operation that could be called IncreaseFeeASC which will, for a specified asynchronous message, increase the amount of fees.

Limitation

It's still needed to monitor the fees market to increase if needed. However this could be done with a little and very short term asynchronous message that maintains long living messages.

Future ideas

• Being notified when your message is out of the pool.

cc @damip