Creating revm-primitives, revm better errors and db components

[rakita]

revm-primitives contain low level structures and traits that rest of the project needs.
It contains big numbers and hash structs, account/storage/byteciode/log structs, env variables, return types, Database traits and some utilities as CREATE address calculation. Task: #304

Bytecode are found in primitives but analysis is left to interpreter as it is instruction related.

Database components are added (State, BlockHash) and wrapper around them. Task: #298

And finally, we are getting proper return types. @Wodann did a lot of investigation here: #309
And they look something like:

pub type EVMResult<DB> = std::result::Result<ResultAndState, EVMError<DB>>

pub struct ResultAndState {
    /// Status of execution
    pub result: ExecutionResult,
    /// State that got updated
    pub state: State,
}

pub enum ExecutionResult {
    /// Returned successfully
    Success {
        reason: Eval,
        gas_used: u64,
        gas_refunded: u64,
        logs: Vec<Log>,
        output: Output,
    },
    /// Reverted by `REVERT` opcode that doesn't spend all gas.
    Revert { gas_used: u64 },
    /// Reverted for various reasons and spend all gas.
    Halt {
        reason: Halt,
        /// Halting will spend all the gas, and will be equal to gas_limit.
        gas_used: u64,
    },
}

and it removes revmjs as it became a burden to maintain.

[Wodann]

@rakita, I was looking at the reference implementation and am now wondering whether CreateContractSizeLimit is considered an exceptional halt:

https://github.com/ethereum/execution-specs/blob/95ef6bf957a4c66993168384cec395ef1a030026/src/ethereum/london/vm/exceptions.py#L115

Wouldn't we be able to catch that by validating the arguments passed to a create transaction at the very start?

Additionally, the WriteInStaticContext is considered an exceptional halt, but we treat is as an internal error. Why the difference? Can we guarantee recovery?

[rakita]

CreateContractSizeLimit Not exactly, as data that is sent with a transaction is used as bytecode that is going to be executed, that bytecode can do anything and return of execution is newly created bytecode that is saved to db.

WriteInStaticContext Is not possible for a call of depth 1(as in the first call or create) it is only possible when call of depth 1 calls opcode STATIC_CALL for depth 2.