Understand the work required for snapshotting and break into tickets

[gordsport]

As part of the Sweeterwater 💦 planning cycle we need snapshotting functionality to restore state from known snapshot without replaying full chain and allow new nodes to catch up quickly.

This ticket is for the core team to understand and find a technical solution for this that can be broken into tickets and implemented via the usual core team process

The tasks to complete this refinement are likely to look something like this (but feel free to amend to suit):

• [ ] Discuss and agreed the best way to break the work down into feature tickets (into it's smallest valuable work items)
• [ ] create a set of coherent feature tickets for the work that can be understood (and implemented) by the whole team and prioritised for development in our Backlog.

To include:

• [x] Co-create feature test scenarios with @cpuja84 - Feature tests aren't needed but essentially manual testing would be done for Snapshotting
• [x] Understand if and what system tests will be required to be implemented by @vega-paul or @eyongegbe
• [ ] Create tickets using the new feature ticket template
• [ ] Add tickets to the Snapshotting project board add link to feature in the Ready to Work on column in priority order
• [ ] Review tickets with the team
• [ ] Create the outline of a spec document for review with (and completion by) protocol-design team - if required

[gordsport]

@vega-paul @cpuja84 the broken out tickets for you to review on this are: Implement the tendermint side of the snapshot handling in the core Implement the per engine snapshot creation and initialisation system Measure the impact of generating a snapshot so we have a baseline idea of how long it takes Create reference doc for snapshot feature

Once done and no other tickets are required this can be moved to done so work can be tracked in the child tickets