refactor: decouple EVMData from Inspector trait

[Wodann]

Currently, the Inspector trait has a Database generic that imposes its lifetime constraints onto the Inspector. This would prohibit user-provided Inspector implementations from being used in async contexts as when the Database implementation is using references, as lifetimes need to be 'static in async contexts.

E.g.

fn build_evm<'s, 'b, E>(
  some_state: &'s dyn StateRef<E>,
  some_blockhash: &'b dyn BlockHashRef<E
) -> EVM<DatabaseComponents<&'s dyn StateRef<E>, &'b dyn BlockHashRef<E>> {
  let mut evm = revm::EVM::new();
  evm.database(DatabaseComponents {
    some_state,
    some_blockhash,
  });
  
  evm
}

fn run_transaction(
  evm: EVM<DatabaseComponents<&'s dyn StateRef<E>, &'b dyn BlockHashRef<E>>,
  inspector: &mut dyn Inspector<DatabaseComponents<&'s dyn StateRef<E>, &'b dyn BlockHashRef<E>>>
) {
  evm.inspect_ref(inspector)
}

The above example illustrates how the lifetimes imposed on the database bleed into the inspector. It is however impossible for a user to create a dynamic object with the lifetime constraints mentioned on the inspector's bounds.

This PR decouples the Database from the Inspector by using a strategy pattern: a trait EVMData<E> that returns a &mut dyn Database<E>

NOTE: This is a breaking change to the existing public API

[rakita]

I think this is the right approach, but I intend to make more breaking changes to the inspector as I would like to have opcode aware inspections ( as in hook to only specified opcodes, or add new opcodes).

I am still not exactly sure how this would look like, it would need to be drop in replacement for current inspector trait, but it would be best to do all of this changes at once to minimize breaking versions.

[Wodann]

If you'd like, I'm more than happy to experiment with and give feedback on different API designs you have 🙂

Do you have a rough estimate for when you plan on incorporating this?

[rakita]

If you'd like, I'm more than happy to experiment with and give feedback on different API designs you have 🙂

Do you have a rough estimate for when you plan on incorporating this?

I don't have any timeline but the idea is kinda broader and requires replacing the interpreter dispatching of opcodes, but i need to experiment a little with that.

[Wodann]

Hi @rakita. We'd like to include this in our release. Is there a chance of getting it in before a next (breaking) release of revm?

[Wodann]

Rebased to resolve conflicts

[rakita]

This could be done inside Handler and EvmBuilder as it has a lot more control: #888
PR is still wip