fix: Override lower bound gas when gasLimit is defined

[pedronfigueiredo]

Explanation

On the extension client, a strange behaviour occurrs when a dApp sends a request with a gasLimit lower than the minimum 21000, but the transaction still is confirmed with a gas of 21000.

This happens because updateGasProperties is called inside addTransaction. updateGasProperties calls updateGas that calls getGas in which if the gas property in the txParams is falsy, it defaults to FIXED_GAS which is 0x5208 (21000). To fix this issue, we can derive gas from gasLimit during normalization of transaction parameters when the first is falsy and the second is defined.

Note that transactions correctly failed when the user tweaked the gas prices using the appropriate modals. This is because gas is derived from gasLimit before new gas settings are submitted to the transaction controller in updateTransactionGasFees.

References

• Fixes: [Bug]: A potential issue where MetaMask may not be accurately respecting the gas values passed from a dApp when the gas settings remain unaltered by the user metamask-extension#30183

Changelog

@metamask/transaction-controller

• FIXED: Derive gas from gasLimit when the first is undefined and the second is defined.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've highlighted breaking changes using the "BREAKING" category above as appropriate
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

[matthewwalsh0]

Rather than adding the support here specifically, is now a good time to instead remove all usages of gasLimit and mark it as deprecated in the TransactionParams type?

Plus update the NORMALIZERS in utils.ts to set gas to gasLimit if gas is undefined?

I'm assuming gas is the best choice going forward as it's the only one defined in our external doc and on ethereum.org.