Add BackendReader trait

[sergerad]

Context

In #967 we created reader traits used by rocks db structs including a new snapshot reader struct.

We need to do the same for the large forest SMT traits and PersistentBackend.

Changes

• Extracts a BackendReader trait from Backend, providing the read-only query interface for the SMT forest storage backend (open, get, get_leaf, version, lineages, trees, entries, entry_count).
• Backend becomes a supertrait of BackendReader, extending it with write operations and an associated Reader type with a reader() method that returns a point-in-time snapshot.
• Adds InMemoryBackendSnapshot — a read-only, snapshot of the in-memory backend — implementing only BackendReader.
• Adds PersistentBackendReader — a read-only view of the persistent backend backed by a RocksDB snapshot, providing a consistent read view isolated from concurrent writes (Similar to RocksDbSnapshotStorage).

[huitseeker]

@sergerad I think this needs a rebase on the squash-merged #967

[sergerad]

@sergerad I think this needs a rebase on the squash-merged #967

Why do you say that? I don't see a problem with the diffs after the base was automatically changed to next. Am I missing something?

[huitseeker]

@sergerad the history of this PR is clean from the diff PoV but not from the commit sequence PoV, as it includes each individual commit of #967 as opposed to a7f748e. Cleaning this up requires a rebase on the latest origin/next.

[sergerad]

@sergerad the history of this PR is clean from the diff PoV but not from the commit sequence PoV, as it includes each individual commit of #967 as opposed to a7f748e. Cleaning this up requires a rebase on the latest origin/next.

Makes sense. But is that not moot given this branch's commits will be squashed before merge?

[huitseeker]

@sergerad FWIW I find helping reviewers navigate PRs faster is one of the most impactful accelerants to shipping overall.

[sergerad]

@huitseeker I have rebased now. Note this branch's commits have been squashed as I avoided manual merging / cherry-picking to perform the rebase. Hope that is OK.

[huitseeker]

@sergerad quite fine! Note a good way to perform this sort of cleanup w/o deleting commit history is to do an rebase (possibly an interactive one to visually check the results) skipping the empty (metadata-only) commits: git rebase ... --empty=drop

[huitseeker]

The main API design question is whether LargeSmtForest should expose a reader() method analogous to LargeSmt::reader(). Without it, callers that already hold a forest cannot obtain a read-only forest snapshot because the backend field is private.

[sergerad]

The main API design question is whether LargeSmtForest should expose a reader() method analogous to LargeSmt::reader(). Without it, callers that already hold a forest cannot obtain a read-only forest snapshot because the backend field is private.

Have added LargeSmtForest::reader()

[huitseeker]

This LGTM!