[Roadmap] Incremental Rust modernization for HugeGraph core modules

## Goal

Explore an **incremental Rust implementation** for selected HugeGraph Server, HStore, and PD components, especially performance- or memory-sensitive paths where Rust can provide measurable safety and efficiency benefits.

This is a parent tracking issue, not a commitment to rewrite the whole server. The current implementation remains the compatibility baseline, and Java/Rust components may coexist behind stable process, protocol, or storage boundaries.

## Roadmap at a glance

```text
Toolchain foundations
│
v
┌─ This repository ─────────────────┐
│ Server core -> HStore -> PD │
└───────────────────────────────────┘
│
v
Computer kernels -> Vermeer/OLAP

Each arrow is a review gate, not an automatic rewrite.
```

## Proposed priority

1. **Server core**
- Begin with bounded leaf components, memory management, codecs, or performance-sensitive data structures rather than the whole request path.
- Preserve REST/Gremlin behavior, authentication, observability, and plugin contracts.
2. **HStore**
- Evaluate storage/replication paths only after workload baselines, on-disk and wire compatibility, failure recovery, and rolling-upgrade requirements are explicit.
3. **PD**
- Evaluate scheduling and metadata components after their distributed-system invariants and compatibility contract are covered by repeatable tests.

The sequence may change based on benchmark evidence and maintainer consensus.

## Delivery model

```text
proposal/RFC -> isolated component -> differential/fault tests
-> benchmark -> opt-in deployment -> staged adoption
```

## Planning guardrails (required)

Before implementation starts, each child issue **must** define:

- scope, owner/mentor, and non-goals;
- API, protocol, storage-format, and operational compatibility;
- differential, concurrency, fault-injection, and upgrade/rollback tests;
- reproducible latency, throughput, memory, and recovery benchmarks;
- security/dependency checks and supported platforms;
- observability, deployment, coexistence, migration, and rollback plans;
- explicit acceptance criteria and user/operator/contributor documentation.

No large rewrite PR should start before its design and acceptance criteria are reviewed. Correctness, recoverability, and compatibility take precedence over headline benchmark numbers. Small, reviewable PRs and stable interoperability boundaries are required; an unplanned rewrite PR may be closed or asked to return to the RFC/design stage.

## Candidate work items

- [ ] Select the first small server-side proof of concept
- [ ] Document stable Java/Rust interoperability boundaries
- [ ] Build shared differential and compatibility test fixtures
- [ ] Establish representative OLTP and storage workload baselines
- [ ] Define CI, packaging, security, and release conventions
- [ ] Define rolling-upgrade and rollback requirements before HStore/PD work
- [ ] Split approved work into newcomer-friendly child issues

This checklist will link to concrete child issues as proposals are accepted.

## Project-wide roadmap

- Toolchain: apache/hugegraph-toolchain#748
- Server / HStore / PD (this issue): apache/hugegraph#3110
- Computer / Vermeer: apache/hugegraph-computer#355
- Documentation hub: apache/hugegraph-doc#462

## How to participate

Interested in **open source, Rust, databases, distributed systems, storage engines, or infrastructure**? Comment with the area you want to work on and any relevant experience. RFC review, failure-model analysis, benchmarks, tests, and documentation are all valuable.

First-time contributors can start with the [HugeGraph contribution guide](https://hugegraph.apache.org/docs/contribution-guidelines/contribute/) and the repository's `good first issue` / `help wanted` tasks.

This is a parent roadmap rather than a concrete code task, with no file or test entry point named. Start by reading the contribution guide and the checklist, then choose a bounded candidate such as interoperability boundaries, differential fixtures, or benchmarks. Done means an approved, scoped child issue with owner or mentor, compatibility and test criteria, benchmarks, and rollout or rollback requirements.

Written by the indexing model from the issue text.