Storage testing

[OlivierBBB]

To properly test storage operations and the new maps one should write multi-block tests where

• in some transactions addresses and storage keys are pre-warmed, including
  • addresses and storage keys that the transaction will interact with
  • addresses and storage keys that the transaction won't interact with
  • in relation to deployments:
  • addresses that don't yet exist but may or may not get deployed during the transaction
  • storage keys in accounts that may or may already exist
  • accounts that don't require pre-warming (e.g. SENDER, RECIPIENT / DEPLOYMENT_ADDRESS, PRECOMPILES --- Note: London does not prewarm the COINBASE address)
  • accounts where pre-warming makes no sense (e.g. COINBASE)
  • storage keys in accounts whose storage is inaccessible (EOA's, precompiles, EMPTY accounts / gibbrerish address accounts)
• storage values are set multiple times, at times going back to the value originally in storage
• storage operations may or may not get undone by a REVERT
• storage operations may get performed during deployment
• storage operations may get performed after deployment
• storage slots may get wiped by SELFDESTRUCT
• having multiple cycles (in one or more transactions) of
  • CREATE2 wherein you touch storage
  • CALL to the deployed contract and touch storage
  • REVERT the deployment
  • recycle

[OlivierBBB]

BTW I would take the opportunity to contact @thedarkjester and @gauravahuja on how to use the new testing framework. We will want to write many tests, bytecode won't be an option, especially when we start mixing CREATE(2)'s, CALL's and SELFDESTRUT's, see https://github.com/Consensys/linea-tracer/pull/1052