Split `sov-rollup-interface` for faster compilation of certain cases

[citizen-stig]

sov-rollup-interface depends on rocksdb with native flag.

But this type only needed for server-side full node, and not needed for:

• Adapters
• Client side crates, FFI bindings, etc.
• Metrics

We need to think what would be a best way to split the rollup-interface into several crates

[Abhisheklearn12]

Hi @citizen-stig, a few questions before starting:

Q1: Feature flag split or crate split?

rockbound is used in exactly one place in the entire crate, the ledger_reader field in StateUpdateInfo inside src/state_machine/mod.rs. Everything else under native (tokio, futures, backon, tracing, the entire node/ module) has zero RocksDB dependency.

A feature split, e.g. rename current native to async-service, then native = ["async-service", "rockbound"], removes RocksDB for all adapter crates by touching 2–3 files. A crate split is cleaner long-term but requires updating every dependent Cargo.toml and all sov_rollup_interface::node::... import paths across the workspace. Which is the intended scope? And if a feature split, what should the intermediate feature be called?

Q2: Where should StateUpdateInfo go?

It's the only struct using rockbound, but it also holds a crate::node::SyncStatus field, a direct reference into the node/ module (re-exported from src/node/mod.rs). Moving it to sov-db breaks that cross-reference. Keeping it here behind a narrower feature means sov-rollup-interface still carries a rockbound dep, just more tightly gated. Should it move out, or stay here behind a more specific feature?

Q3: Acceptance criterion

From the code: all 6 adapter crates (mock-da, celestia, risc0, sp1, avail, mock-zkvm) and sov-node-client currently pull in
rockbound despite not using it. But sov-metrics currently has no dependency on sov-rollup-interface at all, so the metrics mention in the issue is either forward-looking or referring to something I haven't found. Is my list complete, or are there other crates I'm missing?