Provide suggestions for upper and lower bounds for max priority fee

[saledjenic]

For the time being, we're estimating low/medium/high fees as well as the tx time on our side using SuggestedFees and TransactionEstimatedTime functions of the FeeManager.

According to the new Send modal design we need base fee and priority fee ranges, that's something we don't have yet. So we need to think about how to calculate those ranges, while for estimated fees and time, we have some discrepancies comparing those values with Metamask.

Maybe it's a good time to start using suggestedGasFees call that provides all those details instead of calculating them on our side.
https://docs.metamask.io/services/reference/gas-api/api-reference/gasprices-type2

This is what the response looks like:

Since it's a GET call to Infura that is using API key, what's the best way to integrate it into the app?
Do we want to add it to StatusProxy?
Do we need a similar logic we have for rpc providers?

@alaibe @shivekkhurana @friofry @dlipicar @alexjba

[alaibe]

@saledjenic can we call that from any provider or only infura offers it?

[dlipicar]

My opinion:
We should try to keep the wallet as operational as possible using standard JSON-RPC calls, particularly for the most basic wallet operations (fetching balances, send transaction). I know this is already not the case, but it doesn't mean we need to keep moving in that direction.
There's some reference implementations we can use as a guide if we wanted to do this ourselves: https://github.com/brave/brave-core/blob/master/components/brave_wallet/browser/eth_gas_utils.cc#L69

If it's not possible/practical, or as a short term solution until we decide we want to work on the first approach, we can just add the custom Infura API to the proxy. If these results are block-based, make sure we cache them (like I wish we did with prices obtained from CryptoCompare).

[saledjenic]

I was also searching a bit, and yes, the link you shared is a good one to implement.
It's implemented here: status-im/status-go#6243

Initially, I was thinking about https://github.com/zsfelfoldi/feehistory/blob/main/docs/feeOracle.md ( https://github.com/zsfelfoldi/feehistory/blob/main/js/feeOracle.js ) but that's not what we need. Maybe we can use that oracle and map the time factor to some real times (to 30 secs period for example, factor 1, less than 30 secs, factor 2 less than 1 min, factor 4 less than 1.5 min, factor 8 less than 2 mins, since we have factors as a power of 2 up to 128) and use that for calculating estimated time if we're not confident enough in our estimated time algorithm.