VM: EVM Opts Chaining for better DevEx

[holgerd77]

I was a bit shocked when I wanted to integrate the new bls EVM option into the client here (e.g.) that we still have got this ugly DevEx in place that a full fledged EVM needs to be passed over to the VM, even if only a tiny setting or boolean flag should be adjusted (so this then draws this need in to re-provide a full round set of statemanager, blockchain, common,... to align with the VM).

This PR solves this, by just chaining over the EVM options. Should have no side effects, I thought through (and provided with tests) a couple of scenarios, especially regarding blockchain, statemanager, common.

So, if these three are provided to evmOpts (for whatever reasons), one would assume that the calling user has some reason for it and knows what he/she is doing, so then these three take precendence (note that the whole scenario is rather theoretical, this is just "solved for completeness").

Otherwise SM, blockchain, common from the normal VM options take precedense, so behavior from before.

Should be ready to be merged, this should ease the life of other users as well.

[jochem-brouwer]

One comment but LGTM in general

[jochem-brouwer]

Doesn't this:

        common: opts.common,
        stateManager: opts.stateManager,
        blockchain: opts.blockchain,
        profiler: {
          enabled: enableProfiler,
        },
        ...evmOpts

Achieve the same? Or did I miss some side effects? This will first setup the object with the opts settings and then override (if those exist) in evmOpts?

[jochem-brouwer]

(this is a nit, I agree the current state works as well)

[holgerd77]

Needed to have a really careful look on this to be sure, but: yes, I think this works, nice optimization! 🙂

Have updated!

[jochem-brouwer]

Assuming CI will pass, will approve here! 😄 👍