The new checkpoint is the current `last_allowed_fork_level` of the new
head.
When updating the checkpoint the shell tags as invalid all blocks with
a level strictly higher to the new checkpoint that are inconstant with
it. And it removes from the disk all the block with a level lower or
equal to the new checkpoint that do not belongs to the current
chain. Though, the shell removes nothing from the disk when the
current head is below the current checkpoint: this will allow to
configure an expected checkpoint when bootstraping a node.
The first patch is very conservative and only detects new incompatible
blocks when they are stored on disk (i.e. after the validation).
Fiture patches try to detect earlier such incompatible block.
- start using `GET` and query parameters instead of `POST` when
meaningful
- inline parsed protocol data and metadata in block headers
- inline parsed protocol data and metadata in operations
- split the RPC in four categories:
- static data, available explicitly in block headers and operations
- static "metadata", information that were computed while validating
a block or an operation, but which are not explicit in the block
header (e.g. the baker of a block, the list of internal
transfer... (currently not implemented, but that's WIP))
- "context" all the static data we may read in the context
(contracts balance, list of delegates, ...)
- "helpers" are some RPC that may perform some computation.
