core/vm: rework gas measurement for call variants

[jwasinger]

simplified version of #33380

[jwasinger]

There's a lint error, but I don't have perms to push to your branch @rjl493456442 . I'm going to apply this PR on top of the bal changes.

[rjl493456442]

Feel free to reown it!

[rjl493456442]

I would like to revert the changes to EIP7702 wrapper for now, if all clients agree the current spec is the best solution, we can add it back!

[MariusVanDerWijden]

The problem I had with this was that we are computing the intrinsic cost (and with that the readOnly guard) after we potentially added the address to the access list. This could lead to an address ending up in the BAL that was called through a call that should've been stopped by the readOnly guard. I guess our old behavior did the same thing. So the PR is okay, its just something we need to refactor for BALs anyway

[MariusVanDerWijden]

Ah just realized that jared has reordered the clauses to move the readOnly guard first. It kinda duplicates it, but it fixes the issue

[rjl493456442]

Jared modified it a few weeks ago, the gas calculation should be terminated immediately if the readOnly is applied and state mutation occurs.

[MariusVanDerWijden]

SGTM

[lightclient]

nit: I think the "intrinsic" suffix is a bit overloaded with tx intrinsic gas. We can address it later though.

LGTM

[wanyvic]

Issue: duplicated "out of gas" error string in call traces

Summary

Commit fd85963
("core/vm: rework gas measurement for call variants", PR #33648)
changed the CALL gas calculation flow and introduced an observable trace error
string regression.

The semantic VM error is still out-of-gas, but the public trace error string
changed from:

out of gas

to:

out of gas: out of gas

This is visible in debug_traceTransaction and also propagates to persisted
internal transaction traces, because tracers store or return err.Error()
directly.

Observed Behavior

Example transaction:

0xf536a76b7617fe85eaebe807020adeb1d28c6b752472c1cba9ffd3ad99b16181

Observed trace path:

result.calls[0].calls[0].error

Old behavior, v1.16.8 / old CALL gas flow:

"out of gas"

New behavior, v1.17.2 / new CALL gas flow:

"out of gas: out of gas"

Root Cause

Before fd85963, CALL gas calculation returned the full dynamic gas cost to
the interpreter. If the contract did not have enough gas, the interpreter
returned the bare ErrOutOfGas:

if contract.Gas < dynamicCost {
    return nil, ErrOutOfGas
}

Therefore tracers exposed:

out of gas

After fd85963, CALL gas calculation was split into intrinsic/stateless and
stateful parts. The new gasCallIntrinsic path performs an early gas check:

if contract.Gas < gas {
    return 0, ErrOutOfGas
}

That ErrOutOfGas is returned from operation.dynamicGas(...). The interpreter
then wraps all dynamic gas errors here:

if err != nil {
    return nil, fmt.Errorf("%w: %v", ErrOutOfGas, err)
}

Since err is already ErrOutOfGas, the final error string becomes:

out of gas: out of gas

Impact

The EVM semantics are unchanged, but the public trace error string changes.
This breaks downstream compatibility checks and reconciliation jobs that expect
the historical trace error string:

out of gas

The difference affects:

- debug_traceTransaction callTracer output