Transaction analytics by transaction replay

This in an introductory project designed to find some very useful information and perhaps optimisation opportunities for Silkworm execution, at the same time requiring understanding of the code and some aspect of Turbo-Geth/Silkworm data model.
Carrying out this task will require the database obtained by fully syncing a Turbo-Geth node, which should be compatible with the silkworm code. This is because the task requires replaying all transactions from the mainnet history. Of course, for most debugging and testing, only a small subset of transaction should be replayed.

# Goals

Here are 3 high-level goals:
1. Find number of transactions that fail and consume the entire allotted gas. These are "Out of Gas" errors, hitting unrecognised instruction, making invalid jump, or explicitly calling `INVALID` instruction. These transactions do not make any changes in Ethereum state, except for deducting the ETH (`gasprice * tx gaslimit`) from the sender's balance of the transaction, and adding the same amount to the miner's balance.
2. Think about data structure (for example, compressed bitmap) that would allow us to mark the transactions found in `1.` so that we can use this data structure as one of the inputs to replay
3. Using the data structure from `2.`, see if there is a benefit in skipping the execution of these transactions entirely, and how much benefits that could bring.
4. Also using data structure from `2.`, see if we can simplify the configuration of EVM, by retrofitting some opcodes that did not exist from the beginning, and "pretend" that they existed from the very beginning of Ethereum in 2015. For example, bit shifting opcodes, if used prior to Byzantium hard fork where they were introduced, would produce failure of the type described in `1.`, and if we skip these transactions, we can simply pretend that the bit shifting opcodes were always around. Find all such opcodes and see how this can simplify the EVM configuration.

# Tools

Apart from having the synced database, you will need the code that is capable of re-executing any historical transactions at will. Such code exists in Silkworm, in the `silkworm/cmd/check_changes.cpp` file. This command line utility can be used as a starting point, it accept parameters that specify the database, as well as range of historical block numbers for which to re-play transactions.

The way this program works is similar to how transaction replay is done in the "live" mode. The difference here is that instead of reading state items (accounts with their balances and nonces, contract storage items) from the `PLAIN-CST2` table, this historical replay uses the combination of change set tables `PLAIN-ACS` and `PLAIN-SCS`, and history index tables `hAT` and `hST` to read historical state. Unlike the "live" execution, it does not modify the database and is totally read-only, so it is very good for repetitive experiments and learning. If you want to dig deeper how it works, you can refer to the file `silkworm/silkworm/db/buffer.cpp`, which defines the type `Buffer`. An instance of this type is passed into the `execute` function, and this buffer is used to access historical state. Going even deeper, look at the file `silkworm/silkworm/db/access_layer.cpp`, specifically at functions `read_account` and `read_storage`