Support pruning

[theo-zil]

Nodes can currently run with a partial history (by loading from a checkpoint), but it's not a fully fledged feature.

• Add API to query what blocks a node has available
• Make sure RPCs fail gracefully for unknown blocks (might already be the case, just need to check)
• Add dynamic pruning feature - i.e. a config parameter to keep latest N blocks and delete anything older than N from storage

[DrZoltanFazekas]

As an addition to the above, it should also be possible to set the config parameter to a block height we currently don't have (e.g. a block number before the checkpoint from which we synced), to fetch the missing blocks. If the config parameter is set to 0 (genesis), we can sync all blocks older than the checkpoint from which we started syncing.

[DrZoltanFazekas]

When it comes to state pruning, the work on #1503 could make implementing it easier. Think of how Geth vs newer Ethereum clients such as Erigon store the state. The latter ones use a flat key-block-value mapping. @JamesHinshelwood please correct me if I'm wrong

[shawn-zil]

I suspect that the gradual block production throughput degradation in #1970 might have something to do with the growing database indexes. So, if a validator does not hold the entire history, but only a certain number of blocks, the performance degradation might stabilize.