Enforce gas_fee_cap during checking

[aakoshh]

Followup to https://github.com/consensus-shipyard/fendermint/pull/28

The FVM allows the user to send messages with a fee cap which is lower than the base fee, even zero; the miner pays the difference. A validator will probably not want to foot all the bills, though, so the FvmMessageInterpreter should be able to reject messages which are not profitable.

Look at what Forest is doing in the mempool and implement something similar.

[raulk]

The FVM allows the user to send messages with a fee cap which is lower than the base fee, even zero; the miner pays the difference.

Yes, but you seem to be tracking that in consensus-shipyard/ipc-monorepo#323. Let's keep this issue about enforcing (a) correct inclusion behaviour, and (b) mempool queuing logic for when the base fee is higher than the gas fee cap?

At the mpool, this looks like implementing a bounded queue with some heuristics to size it appropriately (e.g. a mixture of count and message size). Today you can assume that most wallets will re-broadcast if a monitored tx gets dropped from the mpool, but to maximise QoS delivered by the netweork, you want to do your best to keep a set of messages around with reasonable criteria (e.g. that could be eligible for inclusion in a future window of N blocks if base fee consistently goes down, up to a max count and size each).

Following what Forest does makes sense, but at this stage we can probably afford to simplify if it's not easy to port the logic over.

[aakoshh]

@raulk you are right, consensus-shipyard/ipc-monorepo#323 is the issue for implementing the logic where the validator should pay the difference, with the caveat of having to specify what to do if they can't.

In this ticket I just wanted to capture that the nodes should have a way of keeping unwanted transactions out of blocks in the first place, with a combination of check_tx and prepare_proposal. We can either reject transactions in check_tx so they don't enter the mempool of the node they were sent to (but other validators can still add them to the block, unless we explicitly don't vote for them, as discussed in consensus-shipyard/ipc-monorepo#323), or we can select the best to be included in prepare_proposal - the rest will be retried by Tendermint later, they aren't removed from the mempool.