Update the hardfork in the transaction common used to estimate L1 opt…

[danjm]

…imism fees to London, fixing display of Layer 1 optimsim fees

Description

The bug was that Layer 1 fees were not being displayed on the confirmation screen for transactions on Optimism.

This was because estimatedL1Fees was null, because fetchEstimatedL1Fee was failing, because TransactionFactory.fromTxData(txParams, { common }) in buildUnserializedTransaction was throwing an error, because txParams has a type === 2, but EIP-1559 transactions are not supported on the spurious dragon hardfork, which is what was being used in the common configuration of that TransactionFactory.fromTxData call.

This became a problem after https://github.com/MetaMask/core/pull/3817/files. That PR correctly fixed a bug which could result in the transaction type being removed from the txMeta.txParams when addTransaction in the tx controller was called. With that bug fix, there was now a type present on the txParams that got passed to the aforementioned TransactionFactory.fromTxData call. Prior to that bug fix, there was no type on txParams at that point, the ethereumjs-tx TransactionFactory was treating these transactions as legacy transactions, and so was constructing a type 0 transaction, and the fact that the hardfork was spurious dragon was not a problem

This PR fixes the problem by updating the hardfork param used in the common configuration of that TransactionFactory.fromTxData call. This should not have a functional effect, as this will cause no change in data and value of the tx passed to the smart contract to generate an fee estimate, except that this may result in more accurate L1 fee estimates (that is not certain though).

Related issues

Fixes: #22945

Manual testing steps

1. Create a transaction on OP Mainnet
2. Click "Fee details" on the confirmation screen
3. The layer 1 fee details should be visible

Screenshots/Recordings

After

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained what problem this PR is solving and how it is solved.
• I've linked related issues
• I've included manual testing steps
• I've included screenshots/recordings if applicable
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (befc516) 68.56% compared to head (371f071) 68.56%.
Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop   #22997   +/-   ##
========================================
  Coverage    68.56%   68.56%           
========================================
  Files         1089     1089           
  Lines        42951    42951           
  Branches     11432    11432           
========================================
  Hits         29446    29446           
  Misses       13505    13505           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.