Add a small-scale DHT benchmark for Chord behavior under network perturbations

[rings-auto-reviewer]

Motivation

The paper currently relies on several classic Chord conclusions for routing/convergence behavior, but the Rings implementation does not yet have a repeatable benchmark that measures those claims against our own DHT implementation.

We should add a small-scale DHT benchmark/simulation suite so we can report implementation-backed numbers instead of only citing the theoretical Chord baseline.

Current code context:

• FingerTable::new already supports a configurable slot count and clamps it to DEFAULT_FINGER_TABLE_SIZE (160); 0 disables finger maintenance.
• SwarmBuilder::dht_finger_table_size and ProcessorBuilder::dht_finger_table_size already exist, so the core path can be configured programmatically.
• The node CLI/config path currently exposes env overrides for settings such as stabilize_interval, ICE servers, and native WebRTC port range, but not DHT finger table size.
• dht_schedule already has a deterministic 6-node controlled-delivery convergence test with a reduced SCHEDULE_FINGER_TABLE_SIZE = 16, which is useful correctness evidence but not a benchmark and not a network-condition simulator.

Proposed Direction

Add a benchmark harness for a small DHT network, initially targeting a 16-node ring, with the DHT finger table size configurable from the environment.

Suggested first scope:

• Add an env/config override for DHT finger table size, for example RINGS_DHT_FINGER_TABLE_SIZE.
• Wire the override through native config/CLI into ProcessorBuilder::dht_finger_table_size.
• Add a benchmark/simulation entrypoint that can run a 16-node DHT with configurable finger table sizes, e.g. 1, 4, 8, 16, and full 160.
• Run repeatable scenarios such as:
  • stable network baseline;
  • message latency distribution;
  • jitter;
  • bounded message loss/drop;
  • delayed stabilization rounds;
  • node churn or temporary unreachability.
• Collect metrics that are useful for the paper:
  • lookup success rate;
  • lookup hop count distribution;
  • stabilization/convergence rounds or wall-clock time;
  • number of DHT/control messages delivered/dropped;
  • finger-table occupancy/quality;
  • recovery time after churn or perturbation.

Design Questions

• Should this be a criterion benchmark, a custom cargo run --example simulator, or both?
• Should the first benchmark use the controlled dummy transport for deterministic replay, or should it exercise a real local transport/cluster path as a second phase?
• Should RINGS_DHT_FINGER_TABLE_SIZE be treated as a general node runtime setting, or only as a benchmark/test override?
• What network perturbations are important enough for the first paper-facing result set?
• What minimum output format do we need for the paper: JSON/CSV summaries, trace files, plots, or just machine-readable raw metrics?

Acceptance Criteria

• A developer can run a reproducible 16-node DHT benchmark locally.
• Finger table size can be overridden from the environment without code changes.
• The benchmark can compare at least two finger-table sizes under the same network scenario.
• The output includes enough machine-readable metrics to support paper tables/plots.
• The benchmark distinguishes correctness/regression tests from performance or simulation metrics.