assets: Bump fee rate or gas cap when applicable.

[JoeGruffins]

Related convo: #1485 (comment)

When an order is made the max fee rate is decided. When a match is made the fee rate is decided. For both account and utxo assets, some time may pass before this rate is used and a tx is sent. So, the fee may be too low at that time. When sending swaps or redeems, we can check the current fee locally, or grab from the server if needed/possible, and increase the rate if necessary. As long as the fee isn't less that what the server wants, it accepts the initiation. Fee is not checked for redeems or refunds.

This is especially important for account based assets, where a low fee can stop everything. Currently the server could send a max fee that is too low, or the fee could just increase a lot as block times are quite short and max would be set at the time of order creation, and the client would have no way to recover.

[JoeGruffins]

Can be done for eth after @martonp makes the client a FeeRater and we can use that to judge if we need to up the max.

[chappjc]

Thanks for making an issue for this @JoeGruffins. I would only add that this issue is mainly for the taker's swap txn because they broadcast quite a bit later than the match time because maker goes first. Also, I think this is most important for assets with both volatile fees and non-dynamic-fee txns (i.e. Bitcoin).

This is especially important for account based assets, where a low fee can stop everything. Currently the server could send a max fee that is too low, or the fee could just increase a lot as block times are quite short and max would be set at the time of order creation, and the client would have no way to recover.

We're really addressing this with dynamic transactions, by having the asset's maxFeeRate be the prescribed swapRate. If server has a maxFeeRate that is too low, there's no way to fix that because we've only funded/reserved enough to cover maxFeeRate. Now, we could check that server actually does prescribe maxFeeRate as intended, but if maxFeeRate is not enough, we cannot go higher for eth without dipping back into the wallet balance for some extra reserved funds, and that may not be possible if all funds are reserved already.

Quoting myself in that other comment:

It should be fine to use any rate x that is on swapRate <= x <= db.OrderMetaData.MaxFeeRate. For a FeeRater, the asset could use it's own rate as long as it is in that range. For a non-FeeRater it could do a c.feeSuggestionAny or a dc.fetchFeeRate.

We can only bump on the above range. For eth, all we can do is just force x to MaxFeeRate if it is not already, but as we've written the server's backend, it will be.