feat: implement manual RPC backup via RocksDB checkpoint (Approach A)

[Zhangcy0x3]

Summary
This PR implements the initial phase of Approach A (RocksDB Checkpoint) as proposed in #1086. It provides a new RPC method backup_now that allows users to trigger a consistent online backup of the node's storage and essential key files without requiring a shutdown.

Key Changes

1. Storage Abstraction & Decoupling
   Introduced the KVStore trait to abstract database handle access. This design decouples the RPC layer from the specific storage implementation, facilitating future maintenance and potential backend swaps.

2. Core Backup Logic (Approach A)
   Integrated RocksDB's native Checkpoint API to create consistent, atomic snapshots of the store. Implemented physical file backup for critical identity files: ckb_key and fiber_key.

3. Architecture & Dependency Injection
   Refactored InfoRpcServerImpl::new to correctly inject Store, CkbConfig, and FiberConfig. Using log_and_error! macro as error handling with structured error objects .

Test Plan
Passed the following integration tests:

test_rpc_backup_now_success: Verifies successful backup creation and file integrity.

test_rpc_backup_now_already_exists: Ensures proper error handling when the target backup directory already exists.

Task List (#1086 Phase 1)

• Manual RPC trigger: backup_now

• Approach A: Scheduled trigger (Planned)

• Phase 2: Recovery capability (Planned)

Related Issues
Relates to #1086

[Zhangcy0x3]

PR Update Summary

I have performed a comprehensive refactoring to resolve the WASM compatibility issues while ensuring the node backup functionality (Approach A) works correctly on native platforms.

Key Problems & Solutions
Dependency Leakage (WASM CI Failure)

Problem: Native dependencies like rocksdb and mio do not support WASM targets, causing compilation errors in CI.

Solution: Used precise #[cfg(not(target_arch = "wasm32"))] guards to isolate all backup-related logic and native imports.

Generic Parameter Mismatch (S: RpcServerStore)

Problem: In WASM, the server module (and its RpcServerStore trait) was originally gated out, causing "unresolved import" and "unused type parameter" errors.

Solution: Introduced a Trait Alias (StoreInfo) to bridge platform-specific storage bounds.

Applied std::marker::PhantomDatain the WASM version of InfoRpcServerImpl to handle the unused generic parameter S while maintaining a consistent struct signature.

API Consistency (Structural Integrity)

Problem: Differing struct definitions between platforms usually lead to messy #[cfg] blocks in the caller's code (e.g., mod.rs).

Solution: Unified the InfoRpcServerImpl::new constructor's signature across all platforms. In WASM, native-only parameters are accepted but safely ignored, allowing the RPC module to be initialized transparently by other modules.

[Zhangcy0x3]

PR Update Summary: Completed Backup RPC implementation with full WASM and Feature-gate compatibility.

I have finalized the implementation of the backup_now RPC. Beyond the core backup logic, a significant portion of this PR focuses on ensuring the codebase remains compatible with WASM targets and various feature combinations.
Key Technical Improvements:

1. Strict WASM Isolation:

• Successfully decoupled native-only dependencies (RocksDB checkpointing and File I/O) from the WASM build path using #[cfg] guards.

• Introduced a platform-agnostic StoreInfo trait alias in info.rs to maintain a unified API signature across all targets.

2. Generic Parameter Management:

• Utilized std::marker::PhantomData in the WASM version of InfoRpcServerImpl to handle the generic storage parameter S without leaking native traits.

3. Storage/RPC Layer Decoupling:

• Migrated the KVStore trait definition to the store_impl module. This not only clarifies the architectural boundary but also resolves the documentation generation conflicts (gen-rpc-doc) by keeping internal storage traits out of the public RPC interface.

[Officeyutong]

Hi @Zhangcy0x3, the current PR looks good to me. Will you continue on doing the restoring part?

[Zhangcy0x3]

Hi @Zhangcy0x3, the current PR looks good to me. Will you continue on doing the restoring part?

Thanks for the review! I'm glad to hear the current progress looks good. Yes, I'd love to continue and implement the restoring part.