core: avoid add l1Cost twice when GasFeeCap is nil

[zhiqiangxu]

The previous code will add l1Cost twice when GasFeeCap is nil, which is very confusing for readers.

This PR makes it less confusing.

[zhiqiangxu]

@protolambda could you take a look?

[protolambda]

I believe this change is correct & safe:

correctness: yes, it would be added twice to balanceCheck if balanceCheck was still set to the original msgval, and not using the gas-fee-cap. The move makes sense w.r.t. readability.

safety: msg.GasFeeCap is always set, there's never a case where it's actually nil. I can add a panic in an else where GasFeeCap == nil, and op-e2e system tests pass. And even things like the legacy tx type get the GasFeeCap by simply returning the full pre-eip1559 gas price. And the RPC code path seems to set GasFeeCap too.

If there is a legitimate case where GasFeeCap could have been nil then we want to avoid this, to not break behavior. That said, alternative execution clients implement this differently already, and if there was a problem we should have long seen the double balance-check difference by now (assuming a low enough balance dust-sweep tx on any op-stack chain occurred).

I would appreciate a sanity-check from a second reviewer here, since this is critical code. cc @ajsutton maybe.

[zhiqiangxu]

Quoted from here about GasFeeCap:

The case where it's nil doesn't happen in practice during block execution.

[ajsutton]

Yeah I agree with that analysis, and the upstream PR adds weight to it as well.