feat(server): add bandwidth-measure generation counter

[Greg Lamberson (glamberson)]

Summary

• autodetect_bandwidth_handle() (feat(server): expose measured bandwidth to the embedder #1734) exposes the latest Bandwidth
  Measure figure, but a consumer doing its own smoothing/filtering on
  top of it (e.g. rejecting noisy low samples unless real demand
  existed) needs to know when a new measurement window has closed,
  not just what the figure currently reads. The figure itself is a bad
  freshness signal: a quiet link reads the same low value for several
  consecutive windows in a row, so diffing it cannot tell "fresh
  window, same result" apart from "stale, no new window yet".
• Adds autodetect_bandwidth_generation, mirroring
  autodetect_bandwidth's exact shape: an Arc<AtomicU32> field,
  autodetect_bandwidth_generation_handle() accessor, and
  with_autodetect_bandwidth_generation_handle() builder method. It
  increments on every completed Bandwidth Measure transaction,
  successful or not: a completed-but-unusable window still needs to
  advance the generation so a consumer's own stale-demand bookkeeping
  gets cleared instead of carrying over into the next window. The
  server increments it with Release after storing the figure, so a
  consumer that loads it with Acquire reads a bandwidth value at
  least as new as the generation it saw.
• Along the way, upgrades the existing bandwidth-measured debug log
  from just the computed bandwidth_kbps to the whole Bandwidth
  Measure Results response, which carries the raw
  byte_count/time_delta_ms inputs. Useful on its
  own for anyone diagnosing why the figure looks noisy against a
  bursty traffic source (as this crate's own damage-driven server
  usage does): the raw inputs make it immediately visible whether a
  low reading came from a genuinely idle window or a short one that
  happened to close early.

Validation

cargo xtask check fmt/lints/tests/typos/locks all pass. testsuite-core
covers the generation handle's default and injection; the increment itself
runs in the private connection loop, which no harness reaches.

Notes

No public API break: both changes are purely additive to
RdpServerBuilder and RdpServer.

[Copilot]

Copilot review overview

🟡 Changes recommended

The relaxed atomics cannot provide coherent generation/value snapshots, and the new transitions lack tests.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Relaxed atomics allow inconsistent generation and bandwidth snapshots · New
• Add tests for generation counter failure transitions · New

What changed in this PR

Adds a generation counter so embedders can detect completed bandwidth-measurement windows.

Changes:

• Exposes configurable bandwidth-generation handles.
• Increments generation for successful and unusable measurements.
• Adds raw measurement inputs to debug logging.

Protocol review found no wire-format changes. Prose verification was skipped because no standalone documentation changed.

File	Description
crates/​ironrdp-server/​src/​server.rs	Stores, exposes, and updates generation state.
crates/​ironrdp-server/​src/​builder.rs	Adds generation-handle injection.

[github-actions]

Independently verified: the additive generation counter mirrors the existing autodetect handle family (builder field, initializers, RdpServer::new parameter, default, accessor) and increments at both Bandwidth Measure completion branches, consistent with AutoDetectManager's clearing semantics. No protocol or API break found. Three low-severity quality issues remain: the bundled log enrichment adds an unreachable!() panic in the PDU-handling loop to extract two debug fields (dead branch today, but a cross-crate invariant with a panic-free, shorter alternative); no test pins the increment-on-both-branches semantics (the None branch advances the generation while the figure reads u32::MAX); and the documented read-generation-then-bandwidth pairing has no cross-atomic ordering guarantee under Relaxed on weakly ordered targets. The two specialist let-else findings describe the same defect and were merged into one published finding.

[github-actions]

This pull request may overlap with #1964.

Both pull requests currently modify the server's handling of PDUs received on the MCS message channel in crates/ironrdp-server/src/server.rs. This PR edits the AutoDetectOutcome::Bandwidth arms inside handle_message_channel_data; #1964 reworks that same function's decode dispatch of message channel data. The shared region means the two would need to be reconciled, though their purposes differ: a bandwidth freshness counter versus recognizing the Initiate Multitransport Response.

This notice is advisory only. Automated review continues as usual, and how these pull requests relate is for maintainers and authors to decide.

Note

LLM-assisted content (no human feedback).