MetaMask
`minSuggestedMaxPriorityFeePerGas` is too broad
Description
Currently, a set of hardcoded minimum priority fee constants are defined:
low - 1GWEI
mid - 1.5GWEI
high - 2GWEI
If the fee oracle returns values below these (i.e., on eth_feeHistory fallback), they are overwritten with the hardcoded minimums, which are suggested to the user instead.
This causes many issues in custom EVM chains with full EIP1559 compatibility, where miners do not necessarily impose a tip for transactions to be included (i.e., PoS networks, where the monetary incentives come through different mechanisms). An extra priority fee might help on high congested blocks, but zero-priority transactions can perfectly fill half-empty blocks. In other words, the miner (or block proposer) still has other incentives to include them.
Proposed solution
Ideally, calculateEstimatesForPriorityLevel function should just proxy the values returned by the oracle without making further assumptions on the payload other than type compliance; and Metamask UI should not force users to provide a non-zero tip (at least not in custom RPC endpoints).
