feat: read-only stateful precompiles

[ARR4N]

Why this should be merged

Adds support for signalling to a stateful precompile that it's running in a read-only context.

How this works

The vm.PrecompiledStatefulRun function signature was becoming bloated so everything except for input []byte has been collapsed into a vm.PrecompileEnvironment. Using a single argument also means that future features won't be breaking changes. A ReadOnly() bool method is available from the env. I called it an environment and not a context so that the idiomatic variable name can be env and not ctx.

Both a StateDB() vm.StateDB and a ReadOnlyState() libevm.StateReader are available from an env. The read-only version never returns nil while the full StateDB() method returns a non-nil state iff not in a read-only state (i.e. when ReadOnly() returns false). Without this, it would be too easy for a precompile implementation to forget to check ReadOnly() before writing to state.

How this was tested

A precompile is in a read-only state when there is at least one STATICCALL in the callstack that led to it being run. This can happen when either (a) there is a direct vm.EVM.StaticCall() to the precompile or; (b) there is a StaticCall() to some other contract that later calls the precompile via any *CALL* op code.

Scenario (a) is tested by extending the existing TestNewStatefulPrecompile test. Scenario (b) is more complex but thoroughly documented in TestPrecompileFromReadOnlyState.

[darioush]

Pretty sure this is OK, it will force the precompiles to have to decide when they are using read-only vs modifying state but that seems a minor change + good for safety to me.

[darioush]

Question: in general is it preferable to define interfaces like this (no param getters) or to have a struct like:

Suggested change

	type PrecompileEnvironment interface {
	type PrecompileEnvironment struct {
	Rules params.Rules
	ReadOnly bool
	StateDB StateDB
	ReadOnlyState libevm.StateReader
	Addresses *libevm.AddressContext
	}

[ARR4N]

Leaving this unresolved to reply to it later because it's a nuanced answer.

[ARR4N]

Pretty sure this is OK, it will force the precompiles to have to decide when they are using read-only vs modifying state but that seems a minor change + good for safety to me.

That was entirely by design. I figured that since there would already be read-only checks that would have to be refactored to use the env that the refactor of the stateDB variable could be conditioned on that since it too would have to change. There shouldn't be any need to change the rest of the code (assuming it assigns the DB to a variable) since the methods are identical between StateDB and StateReader interfaces.