feat: apply latest EIP-7702 changes

[klkvr]

Applies changes from ethereum/EIPs#8969

Instead of Eip7702CodeLoad code reading methods now return StateLoad and only account for cost of loading the target account

[klkvr]

@rakita how should we deal with failing state tests?

[rakita]

@rakita how should we deal with failing state tests?

We should wait for tests to be released before merging it.

In general, changes look good, but there are two things here:

1. When is this going to be included (devnet-n)
2. Should Revm devnet changes be in the branch as there is a devnet branch in reth. This would mean patches/gitpath in revm-inspector and reth

[klkvr]

1. When is this going to be included (devnet-n)

Seems that in devnet-5 https://notes.ethereum.org/@ethpandaops/pectra-devnet-5

2. Should Revm devnet changes be in the branch as there is a devnet branch in reth. This would mean patches/gitpath in revm-inspector and reth

For devnet-4 changes we were pretty much always just pushing them to main in both alloy and reth. Separate branch was just for convenience when providing devops team with the latest version

[rakita]

1. When is this going to be included (devnet-n)

Seems that in devnet-5 https://notes.ethereum.org/@ethpandaops/pectra-devnet-5

Cool, good link, it is in next releas,more on changes here: https://discord.com/channels/595666850260713488/745077610685661265/1302999973167759416

Let's delay it until Mekong is near it's end.

2. Should Revm devnet changes be in the branch as there is a devnet branch in reth. This would mean patches/gitpath in revm-inspector and reth

For devnet-4 changes we were pretty much always just pushing them to main in both alloy and reth. Separate branch was just for convenience when providing devops team with the latest version

I want to break the notion that this was good behavior, as it pulls the narative that participating in devnet would require publishing crates. Having this charges in a branch is more on the lime of concept of dev chain

[rakita]

lgtm