feat: SS Pruning Support

[alexanderbez]

Description

Closes: #17279

Implement pruning support for SS backends. The idea is that when an SS is provided to a RootStore, the RootStore will call Prune on the SS backend when appropriate.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• run make lint and make test
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[github-actions]

@alexanderbez your pull request is missing a changelog!

[cool-develope]

I'd like to pass the pruning option to the dedicated db, instead of the exposed endpoint.

• avoid the conflicts with sync
• it would be easy to apply pruning at the dedicated backend, (background running)

[alexanderbez]

The problem with making it entirely be the SS engine's responsibility, is when do you prune? The SS interface is just a CRUD API -- there's no notion of "committing".

So when the RootStore commits, how/when does the backing SS store know what/when to prune? You'd need to either do it:

• On every Put and Batch.Write call
  • Note, doing it on Batch.Write would be essentially analogous to doing it on commitment, but the abstraction seems pretty messy to me personally.
• Or, have some sort of external goroutine process in the SS impl that periodically checks and prunes.

So there's tradeoffs to each, but to me having the RootStore simply call Prune on the SS backend seems the cleanest.

Thoughts @tac0turtle or @kocubinski?

[cool-develope]

tbh, I have no exact idea how the sync flow looks like but the original store has snapshot and pruning managers and do some duplicated checks like version conflicting. so I'd like to pass this logic to the dedicated backend and maybe can manage it in background routine or whatever the dedicated backend wants

[alexanderbez]

That introduces additional complexity and goroutine management, but I can add that to the design doc and we'll discuss next meeting.