feat(store/v2): Support Non-Consensus Writes to SS

[alexanderbez]

Description

Closes: #18467

Changelog

• Some general cleanup/linting
• Support non-consensus writes to SS, while ensuring such data will be synced to SS during State Sync

TODO:

• Provide API(s) that allow R/W to SS from a module or any caller with access to the RootStore
• Ensure we handle State Sync extensions s.t. the data can be restored to SS during State Sync
• Tests

---

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
• confirmed ! in 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
• reviewed "Files changed" and left comments if necessary
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• updated the relevant documentation or specification, including comments for documenting Go code
• 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 all author checklist items have been addressed
• reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

[alexanderbez]

Keeping this as blocked until there's better uniformity and a clearer picture between store/v2 and server/v2.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[itsdevbear]

Hallelujah

[tac0turtle]

is this still blocked?

[alexanderbez]

So after giving this some more careful thought, I've come to the conclusion we do not need anything extra here. Here's my rationale:

The data SS stores, by definition, is already non-consensus. Thus, we don't need to expose any extra or special APIs to store non-consensus data.

So there are two things we need to ensure:

1. The ability for modules to get direct R/W access to VersionedDatabase. This will probably be from Environment?
2. State sync snapshots will be created off of SC data, which means new nodes won't have non-consensus data. So we need document that modules that explicitly store non-consensus data, must implement and register ExtensionSnapshotter

re (2), I will document that in #19502