Introduce Archival functionality

[ureeves]

Summary

After much discussing different node roles and archival storage, in the context of features such as hyper-fast syncup and recovery checkpoints, we thought that the best way to go would be to simply allow for a node to be compiled in such a way as to copy commits for safe-keeping according to a certain configuration.

This is essentially the beginning of "archival" node functionality and would allow us to keep historical snapshots of the state of the chain for potential future retrieval and secure chain sync-up. The genesis of this idea is a conversation between myself and @herr-seppia that culminated in the closing of PR introducing multiple recovery checkpoints.

With this feature it should be possible for a node to conditionally compile-in code that:

• Keeps commits that match a given criteria, configurable using the config files
• Allows clients to:
  • List the available commits on the node, allowing the client to understand which commits in can query.
  • Query the state of available commits. This will allow understanding the state of the contracts in time.
  • (optional) Download the whole state. If choosing to do this, keep in mind this can grow to be a lot of data, and should be able to happen cryptographically secure.

Possible solution design or implementation

To implement this, the most expedient way is to modify the way in which we delete commits to not delete commits that match a certain criteria (e.g. is an epoch commit). Code to achieve this is already semi-explored, and exists in the branch behind the closed PR.

This code should be placed behind a new crate feature, (e.g. archival) that gates the above code together with the new API introduced for clients to interact with the list of held commits. In deciding the shape of this API, take into account the already existing (legacy) query API, as well as the new RUES API.

These two things ensure one can have two different types of node - Full Node, and Archival Node.

Additional context

Changes in piecrust will likely not be required to make this work. However, depending on the method chosen to retain commits, care must be taken to not delete commits while copying them.

This comment contains an embryonic version of this idea.