Export snapshot with more metadata

This MR aims to fix an issue while baking just after importing a snapshot. Indeed, it appears that the baker requires the metedata of the predecessor's predecessor of the current head to be able to bake. Here is the error:

[12:00:47.951] [baker-1] Jun 18 12:00:47.951  ERROR │ failed to forge block for baker_17 (tz1YzMXTGVr1o9WCHPHKvnuQZk2kxEitnLNn) --
[12:00:47.951] [baker-1] Jun 18 12:00:47.951  ERROR │   Error:
[12:00:47.951] [baker-1] Jun 18 12:00:47.951  ERROR │     Unable to find block BMP7FaJqdCzqdHBpZCW9m7EmHVMmzieaUWMSKoHh2kj56MEBCdH's metadata.
[12:00:47.951] [baker-1] Jun 18 12:00:47.951  ERROR │

This MR introduces a new snapshot version (v9) that now exports the metadata of the block preceding the predecessor snapshot's target.

This adds very few bytes to the snapshot and should not affect the size of it that much.

It also update the checkpoint and savepoint of the store when a snapshot is imported. This change is particularly tricky. Here is a small explanation that could help: "In this context, savepoint and checkpoint are the same. However, to be valid they need to reflect a block that stores context+block_header+metadata. Before this MR, and after a snapshot import, only the head of a snapshot was of this form. As now, with v9 snapshots, the metadata of the head's pred is exported/imported, the head's pred fulfilled the above constraints. Thus, we can set it as the new checkpoint/savepoint. Note that to be valid, the checkpoint/savepoint also need to have max_op_ttl predecessors. That's why this MR also extends the block history so that we have the max_op_ttl predecessors of head's pred (instead of the max_op_ttl predecessors of the head)."

Manually testing the MR

Import the new snapshot in a scenario were you are facing the above issue.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR