[Tooling][Savepoints/Rollbacks] Implement RPC endpoints for Snapshots/Rollbacks (no-op / faked)

[deblasis]

Objective

The RPC layer should allow the triggering of snapshot creation, rollbacks and also basic queries about the available snapshots (this can become useful later as we develop alternative sources for snapshots)

Note: This issue can be worked on in parallel by calling no-op/fake methods in the backend (handlers.go) for now. When the savepoints/rollbacks are fully implemented, we can wire things together with the real implementation in the follow-up ticket (#570)

Origin Document

493 and #562

Goals

• Create a v1/persistence/snapshots/create endpoint that handles snapshot creation and returns metadata about the snapshot just created.
• Create a v1/persistence/snapshots/list endpoint that simply returns a list of the snapshots available, implement it using an abstraction for the SnapshotSource so that we can swap, in the future, different implementations to target different sources (Tor, FTP, S3, etc). For now proceed with the simplest implementation possible: local filesystem, in a configurable folder.
• Create a v1/persistence/snapshots/rollback endpoint that allows to trigger a rollback by proving an identifier for the snapshot being used as source, in the future this should also support multiple sources as well therefore the same SnapshotSource should be used as a "filesystem abstraction"
• Implement some form of progress reporting, it can be done in multiple ways one is as follows:
  • Whenever a rollback is started, a "job" with an ID is created
  • While the rollback goes through its internal steps, the progress is updated referencing this jobs data structure (could be in memory, TBD)
  • When the user started the rollback, this ID is returned to them so that they can poll an hypothetical v1/persistence/snapshots/progress endpoint which would return what's stored in the datastructure above to the user.

Deliverable

• [ ] A PR with implementation tending to the goal above
• [ ] Updated RPC openapi.yaml with descriptions of the various endpoints, schemas, examples, etc. similar to the other endpoints.

Non-goals / Non-deliverables

General issue deliverables

• [ ] Update the appropriate CHANGELOG(s)
• [ ] Update any relevant local/global README(s)
• [ ] Update relevant source code tree explanations
• [ ] Add or update any relevant or supporting mermaid diagrams

Testing Methodology

• [ ] Task specific tests or benchmarks: make ...
• [ ] New tests or benchmarks: make ...
• [ ] All tests: make test_all
• [ ] LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md

---

Creator: @deblasis Co-Owners: @Olshansk

[h5law]

Is this ticket ready to be implemented? I am unsure what the metadata returned by /v1/persistence/snapshots/create would look like (in the OpenAPI YAML spec for example). I realise the logic in handlers.go can point to some placeholder functions but is there any defined structure for what should be returned and stored locally? Or is that also a part of this PR?

[Olshansk]

There's still a fair bit of work before this piece is ready. @deblasis or I will follow up once it is.