[WIP] Implementation of EOF static relative jumps and functions

[harkal]

!!!This is WIP!!!

What I did

• New opcodes support RJUMP, RJUMPI, JUMPF, CALLF, RETF
• Enhanced the assembler to track function splits and produce the information required to emit proper EOFv1 bytecode
• Updated the opcode utility functions:
  • to support reverse mapping of opcodes to mnemonics
  • detect terminating opcodes
  • get the number of immediate values for every instruction
• Removed the support for JUMPF
• Removed the support for PC
• Support for creating a "bundle" of two consecutive EOFv1 bytecodes in a single container for deployment. While the commands for copying the code continue to operate on the whole container
• Made reject into a function call
• Removed the pushing of return addresses in the operand stack, as CALLF, and RETF operate on the new execution stack automatically
• Modified the opcode output so that it shows the functions and their properties (inputs, outputs, max stack height)
• Created a validation library and cli tool to validate EOFv1 bytecode, to be used for testing the compiler's output. This is currently always active on the compiler, but can be part of automated tests eventually. Validations that currently happens:
  • Headers and version
  • The existence or not of mandatory EOF sections
  • The order they come at
  • Limits on the number of code sections, types and data
  • The proper sequencing of the streaming headers, code and data and whether it all makes sense and finishes exactly where it should
  • Validates the inputs, outputs are in rang. Zero for the first code segment
  • Validates each code segment for valid instructions with proper number of immediates
  • Checks relative jumps and conditional jumps for out of bound destinations
  • Checks for invalid code section ids for CALLF
  • Checks is the opcodes don't go over section's end
  • Checks if last opcode of each code section is a terminating one
  • Checks if relative jumps don't end up in immediates
• Manually tested 'actual' execution of several small EOFv1 programs with the use of geth's evm
• Added the --experimental-eof command line argument that enables all of the new functionality and made sure everything else works like before without it
• Calculate the max stack height for every function

What is next

• Possibly separate the responsibilities for IR nodes label, goto, exit_to and possibly add a call and return node to make it for cleaner, more understandable code.
• Get an EVM that supports EOFv1 and integrate it, so we can start full testing. Finally, there are several implementations that support it, however not pyevm as far as I can tell. Plugging in a different one seems like a lot of work. Maybe bringing pyevm up to speed, especially now that there are other implementations out, is going to be more efficient?

[ziogaschr]

shanghai is not needed anymore I think, as we are introducing it in this PR.

[harkal]

What is the proper way to handle this here? Should I skip shanghai completely? I was worried it might cause problems somewhere else. For example the --evm-version parameter will not accept it anymore (not that it changes anything). If other forks are missing I guess it's totally ok to remove it.

[ziogaschr]

@charles-cooper I think mentioned it's fine if we don't have all forks defined here.