[Rust roadmap] OLTP and storage workload baselines plus rolling-upgrade/rollback requirements for HStore and PD

[SebastianGruza]

Parent: #3110, checklist items "Establish representative OLTP and storage workload baselines" and "Define rolling-upgrade and rollback requirements before HStore/PD work".
Sibling: apache/hugegraph-toolchain#772 (shared data generator; there the loader is measured as a client, here the server and the storage).
Does not overlap with #3145 (codec fixtures, PoC selection matrix).

Scope

1. OLTP baseline. A fixed mix on a shared dataset (CI profile 100k vertices / 500k edges, full profile 5M / 25M): point read by id, 1-hop and 2-hop over edges, a secondary-index query, batch insert, batch update with the SUM strategy, Gremlin g.V().has(). For each: p50/p95/p99, throughput, server RSS and heap, on rocksdb (single node) and on hstore (1 PD + 3 Store, Helm chart from feat(helm): add HStore deployment chart hugegraph/hugegraph#221). A Python harness against REST; results as markdown plus raw JSON.
2. HStore storage baseline. After loading the full profile: size of storage/ split into db, raft log and snapshot; duration and effect of a forced compaction; snapshot duration; time to rebuild a replica after a Store loses its disk; replication lag under writes. Method from hugegraph-store/docs/operations-guide.md and my earlier measurements.
3. Rolling-upgrade and rollback requirements for HStore and PD. A written list of requirements, each with a harness test that checks it and with today's result: (a) Server upgrade under load without losing acknowledged writes and with a bounded error window (today: 30 s from fix(store-client): enhance thread interrupts in NodeTxExecutor #3204, oracle clean in 3 passes); (b) Store upgrade one node at a time keeping quorum and without partition rebalancing; (c) PD upgrade with a leader, including the single-PD case (today: [Bug] A single-node PD never recovers raft leadership after a failed periodic snapshot (disk full), even once the disk is freed; /v1/health stays 200 and /v1/ready hides the error state #3222, no re-election after an error); (d) rollback of each component by one version with data written by the newer version (on-disk format, meta in PD, cluster prefix from [Bug] Server upgraded from 1.7.0 with usePD=true reads an empty schema: meta cluster prefix 'hg-test' vs hardcoded 'hg' #3219); (e) mixed Server/Store/PD versions for the duration of an upgrade. Output: docs/upgrade-requirements.md in hugegraph-store/docs with a requirement / test / status table.

Non-goals

• No Rust, no JNI, no production code changes; harness and documents only.
• No codec fixtures ([Proposal] Java compatibility fixtures and PoC selection matrix for the Rust modernization groundwork #3145) and no loader benchmarks (toolchain v0.10 failed to start with "Not found key AGGREGATE_TYPE" #772).
• No tuning: the baseline measures the default configuration of the chart and of the distribution; tuning is separate work.

Acceptance criteria

• The harness reproduces the CI profile with a single command against a server from the distribution (rocksdb) and against the chart (hstore); the full profile is published with hardware configuration, versions and logs.
• Every requirement in item 3 has a test that exercises it and a recorded result on the current master; requirements not met today are marked explicitly (e.g. [Bug] A single-node PD never recovers raft leadership after a failed periodic snapshot (disk full), even once the disk is freed; /v1/health stays 200 and /v1/ready hides the error state #3222), not hidden.
• Documents in the repo: docs/workload-baselines.md (numbers and method) and docs/upgrade-requirements.md; the harness under hugegraph-server/hugegraph-dist/scripts/baseline/ or wherever review points.

PR plan

#	content	when
1	OLTP harness (CI profile) plus the generator shared with toolchain #772, numbers from rocksdb and hstore on the cluster, docs/workload-baselines.md	+1 week after PR 1 in #772
2	HStore storage baseline and the replica-rebuild test, added to the same document	+1 week
3	docs/upgrade-requirements.md with the upgrade/rollback harness (5 requirements, results on master)	+2 weeks

[SebastianGruza]

Requirement (d) already has a measured counter-example: #3224 (1.7.0 batch data under the missing graph id 0xFFFE becomes unreachable once master allocates a real id at the upgrade restart or the first batch write; rollback does not restore it). The cycle-4 harness in the validation repo is the acceptance test for that requirement.