feat: add support of eth_estimateGas for L1 transactions

[jonesho]

This PR implements issue(s) #3898

Checklist

• I wrote new tests for my new core changes.
• I have successfully ran tests, style checker and build against my new changes locally.
• I have informed the team of any breaking changes if there are any.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 52.52525% with 94 lines in your changes missing coverage. Please review.

Project coverage is 68.06%. Comparing base (845dded) to head (3d5be0f).

Files with missing lines	Patch %	Lines
...nsensys/linea/contract/Web3JContractAsyncHelper.kt	47.97%	58 Missing and 19 partials ⚠️
...ys/linea/contract/l1/LineaRollupEnhancedWrapper.kt	28.57%	5 Missing ⚠️
.../consensys/zkevm/coordinator/app/L1DependentApp.kt	0.00%	4 Missing ⚠️
...ys/zkevm/coordinator/app/BlockchainClientHelper.kt	0.00%	2 Missing ⚠️
...contract/l1/Web3JLineaRollupSmartContractClient.kt	93.54%	2 Missing ⚠️
...kotlin/net/consensys/linea/web3j/Eip4844EthCall.kt	0.00%	1 Missing and 1 partial ⚠️
...ensys/linea/web3j/EthCallWithInformativeReverts.kt	33.33%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #694      +/-   ##
============================================
- Coverage     68.37%   68.06%   -0.31%     
- Complexity     1197     1207      +10     
============================================
  Files           326      326              
  Lines         13326    13402      +76     
  Branches       1350     1354       +4     
============================================
+ Hits           9111     9122      +11     
- Misses         3658     3719      +61     
- Partials        557      561       +4     

Flag	Coverage Δ		*Carryforward flag
hardhat	98.52% <ø> (ø)		Carriedforward from 4136437
kotlin	65.74% <52.52%> (-0.32%)	⬇️

*This pull request uses carry forward flags. Click here to find out more.

Files with missing lines	Coverage Δ
.../zkevm/coordinator/app/config/CoordinatorConfig.kt	77.27% <100.00%> (+0.05%)	⬆️
...ys/zkevm/coordinator/app/BlockchainClientHelper.kt	0.00% <0.00%> (ø)
...contract/l1/Web3JLineaRollupSmartContractClient.kt	91.13% <93.54%> (-1.27%)	⬇️
...kotlin/net/consensys/linea/web3j/Eip4844EthCall.kt	74.19% <0.00%> (-5.81%)	⬇️
...ensys/linea/web3j/EthCallWithInformativeReverts.kt	71.42% <33.33%> (+2.19%)	⬆️
.../consensys/zkevm/coordinator/app/L1DependentApp.kt	1.45% <0.00%> (-0.01%)	⬇️
...ys/linea/contract/l1/LineaRollupEnhancedWrapper.kt	58.33% <28.57%> (-19.45%)	⬇️
...nsensys/linea/contract/Web3JContractAsyncHelper.kt	44.81% <47.97%> (-6.92%)	⬇️

... and 1 file with indirect coverage changes

[Filter94]

This doesn't quite makes sense because getGasLimit already does what executeEthCall is supposed to do if useEthEstimateGas is enabled

[jonesho]

Yes, I was thinking the same but indeed it's a bit different, if useEtheEstimateGas is enabled, we would call eth_estimateGas to estimate the gas limit and then explicitly set it as the gas field in the subsequent eth_call to double check against if the "estimated gas limit" is sufficient enough, given that "estimated gas limit" is not a guarantee and could sometimes be insufficient when being used in eth_call or eth_sendRawTransaction

In practice, this mismatch can happen, especially in complex transactions or when dealing with contracts that have unpredictable gas usage. To mitigate this:

• Test with eth_call: Before relying on the estimate for a real transaction, simulate the call with eth_call using the estimated gas to see if it holds up.

wdyt?

[Filter94]

It makes sense with a static limit, but when useEtheEstimateGas is set, I don't really see any point in eth_estimateGas -> eth_call -> eth_estimateGas -> eth_sendRawTransaction flow.

[Filter94]

I think we'll have an issue with blob submissions.

For blob submission the way things work now we'd send 1 eth_estimateGas for the first set of blobs, which would succeed. But if we're sending more than 6 blobs in a single BlobSubmissionCoordinator tick, I think eth_estimateGas would fail for the second sendBlobs transaction. Meaning that essentially BlobSubmissionCoordinator will be restricted to 1 blob submission per tick. That shouldn't disable anything functionally, but I think it may result in some errors in the logs