refactor: inject call to CREATE2 factory through custom revm handler

[klkvr]

Motivation

ref #7632 (comment)

This changes flow for CREATE2 deployments routed through CREATE2 factory. Earlier we would just patch the sender of CREATE2 frame which resulted in data appearing in traces and state diff being different from the actual transaction data.

The way this PR addresses this is by implementing a revm handler register which replaces CREATE2 frame with CALL frame to factory when needed.

Thus, trace of a simple counter CREATE2 deployment changes from:

[47791] DeployCounter::run()
  ├─ [0] VM::startBroadcast()
  │   └─ ← [Return] 
  ├─ [12666] → new Counter@0xbe77DC606202Cf861Ba32c026c42926c34b62C40
  │   └─ ← [Return] 63 bytes of code
  └─ ← [Stop] 

to:

[79908] DeployCounter::run()
  ├─ [0] VM::startBroadcast()
  │   └─ ← [Return] 
  ├─ [44783] Create2Deployer::create2()
  │   ├─ [12666] → new Counter@0xbe77DC606202Cf861Ba32c026c42926c34b62C40
  │   │   └─ ← [Return] 63 bytes of code
  │   └─ ← [Return] 0xbe77dc606202cf861ba32c026c42926c34b62c40
  └─ ← [Stop] 

Solution

Implement InspectorExt trait with should_use_create2_factory method returning false by default which allows our inspectors to decide if the CREATE frame should be routed through create2 factory.

Implement handler register overriding create and insert_call_outcome hooks:

• Overriden create hook returns CALL frame instead of CREATE frame when should_use_create2_factory fn returns true for the current frame.
• Overriden insert_call_outcome hook decodes result of the create2 factory invocation and inserts it directly into interpreter.

Solution is not really clean because I had to duplicate parts of call and insert_call_outcome hooks from revm inspector hander register instead of just invoking them in register. The motivation behind this is following:

• overriden CREATE2 invocation must be treated as a CALL by inspectors and EVM itself, however, its output should be written to interpreter as CREATE2 output which is different than CALL output in terms of stack and memory operations. Thus we can't reuse insert_call_outcome hook because it would invoke inspector.insert_call_outcome().
• because we can't invoke insert_call_outcome, call cannot be reused as well because we'd mess up internal stack of inspector handler register (https://github.com/bluealloy/revm/blob/f4f4745e00b1c2907b6a3527eee3765bc1603b58/crates/revm/src/inspector/handler_register.rs#L167)

This impl lets us keep cheatcodes inspector and overall flow simpler however it introduces additional complexity in EVM construction step and might result in issues if revm implementation of inspector handler register changes, so not sure if we should include that

[mattsse]

this is great,
only have pedantic doc nits for the register function

[mattsse]

lgtm, pending @DaniPopes

[DaniPopes]

unused

[DaniPopes]

Suggested change

	let account = ecx.journaled_state.state().get(&broadcast.new_origin).unwrap();
	let account = ecx.journaled_state.state()[&broadcast.new_origin];

[DaniPopes]

Suggested change

[DaniPopes]

up

[DaniPopes]

does this need to be public?