feat(server): measure and report network characteristics

[Greg Lamberson (glamberson)]

Summary

• The server measures round-trip time and bandwidth from the continuous
  auto-detect exchange and reports both to the client in a Network
  Characteristics Result on the MCS message channel ([MS-RDPBCGR] 2.2.14.1.5).
• Nothing is sent until both are known. A result carrying RTT alone reports part
  of the picture as though it were the whole, which is what krdp and grd avoid by
  returning early when they have no bandwidth figure.
• The result is paced at one per second on its own clock rather than once per
  probe, and is withheld unless a client response has arrived since the last one.
  A client that stops answering stops producing results instead of leaving the
  last window values advertised indefinitely.
• baseRTT is the lowest RTT seen over the session, per 2.2.14.1.5's "lowest
  detected round-trip time". averageRTT is the window average, so the
  difference between them is queueing delay.

Validation

• cargo xtask check fmt/lints/tests/typos/locks and cargo xtask wasm check
  all pass.
• cargo semver-checks -p ironrdp-server --baseline-rev master: no update
  required.
• Tests live in ironrdp-testsuite-core. ironrdp-server sets
  [lib] test = false, so an inline module would compile and never run. Each new
  test was checked by planting the corresponding regression and confirming it
  fails.

Notes

• Supersedes feat(server): measure bandwidth and report it in NetworkCharacteristicsResult #1471, which added bandwidth as a follow-up. With the gate above,
  this PR alone could only ever emit the form it now declines to send, so the two
  are one change.
• refactor(server)!: take auto-detect timestamps from the caller #1487 has merged, so the earlier dependency note no longer applies.

[Benoît Cortier (CBenoit)]

Two blocking correctness issues remain: validate NETCHAR headerLength against the request-specific permitted values before accepting the PDU, and prevent allocation of an RTT sequence number that is still outstanding after the 16-bit sequence space wraps.

[github-actions]

The PDU-layer part is sound: `netchar_result_rtt` produces exactly the 0x0840 field set that the pre-existing `netchar_fields`/encode/size/decode paths agree on, and the new 14-byte wire vector uses distinct baseRTT/averageRTT values, so a field transposition would fail. No wire-format or encode/decode defect found. The concerns are server-side. The only stated justification for emitting the result is a receive-buffer rationale attributed to a section that (per the handoff's quotation) does not state it; there is no in-repo consumer, and the emission doubles auto-detect PDU volume per tick. Separately: baseRTT is a sliding-window minimum but documented as "lowest observed" and can rise mid-session; RTT samples never expire though probes do, so results keep advertising stale metrics; and both new server-path tests use identical 20 ms samples, so min and average are indistinguishable and swapping the two arguments would still pass.

Protocol analysis: partially_accepted — Kept three items. The 1.3.9 phase tension is unresolved in the corpus, so I report it as a question, not a violation. The window-scoped baseRTT concern is sharpened into a semantics/doc defect, since build_netchar_result's doc says "lowest observed". The unsupported receive-buffer citation is kept as a doc-accuracy defect under the repo's spec-traceable-docs rule. Rejected two: the missing client-capability-flag check and the mcsSDin initiator value both concern the pre-existing, unmodified guard and encoder the RTT request already used. Partially accepted the cadence item: doubled PDU volume is folded into the motivation question, but a result lagging the newest probe by one round is unavoidable, not a defect. Spec text is taken from the handoff as evidence.

1. question / medium — crates/ironrdp-server/src/server.rs:1476-1479
   What concretely motivates emitting a Network Characteristics Result at all? The change adds an unsolicited PDU to every client on every probe tick, doubling auto-detect traffic, and the only benefit stated anywhere is the adjacent comment's receive-buffer-sizing claim, which the handoff's quotation of 3.2.5.14 does not support ("Extract the network metrics from the PDU" is the whole client-side rule). Nothing in the repository consumes it, the manager measures no bandwidth so the report is partial by construction, and the server already surfaces RTT to its own backend via autodetect_rtt_handle. Without a named consumer or an observed client behaviour that requires it, this is added protocol output with unverified interop cost and no demonstrated gain. If the driver is a specific client that expects the result, please say which and how the improvement was observed; that also determines whether per-probe cadence is right.
2. question / medium — crates/ironrdp-server/src/server.rs
   This emission happens on the main connection after the connection sequence completes, paired with an RTT_REQUEST_CONTINUOUS probe. Per the handoff, section 1.3.9 lists Network Characteristics Result among the server-to-client messages for Connect-Time detection and, for continuous detection, inside RDP_TUNNEL_SUBHEADER on sideband channels, but omits it from the continuous main-connection list (only 2.2.14.1.1, 2.2.14.1.2 and 2.2.14.1.4), while 2.2.14.3 permits any of the five messages with no phase qualifier and 0x0840 carries no phase discriminator (unlike 0x0001 vs 0x1001 for RTT). The tension is unresolved, so this is not established as a violation, but it is where a strict client keyed to the 1.3.9 continuous set could treat the PDU as unexpected. Was this validated against a real client (mstsc and/or FreeRDP) in the continuous phase, and what was observed?
3. non_blocking / medium — crates/ironrdp-server/src/autodetect.rs:65-77
   The doc says the result carries "baseRTT (lowest observed)", but snapshot().min_ms is the minimum over the 8-entry sliding window (RTT_WINDOW_SIZE, line 14), not over the connection. Record one 5 ms sample, then eight samples of 100 ms: the 5 ms entry is evicted and the next result reports baseRTT = 100 even though 5 ms was detected, so successive results can report a baseRTT higher than one already sent. A client treating "lowest detected round-trip time" as a monotone floor sees it rise. Either track a session-lifetime minimum in the manager (a single u32 field, no new API) or state the window scope explicitly so the value is not overclaimed. The handoff notes the corpus does not scope baseRTT to a window, so this is a semantics/doc mismatch rather than a proven violation.
4. non_blocking / medium — crates/ironrdp-server/src/autodetect.rs:69-78
   rtt_samples is never aged out — only pending_probes are, via expire_stale_probes. If a client stops answering probes (network stall, suspended client), every subsequent tick still emits a result advertising the last-known window values as the current average and lowest RTT, indefinitely and with no bound on staleness. Before this change the snapshot was pull-only and its freshness was the embedder's problem; making it protocol output turns it into a claim the peer may act on. Consider gating emission on sample freshness (e.g. skip when the newest sample predates now_ms by more than RTT_PROBE_MAX_AGE_MS, which needs a per-sample timestamp) or on at least one response having arrived since the previous result.
5. non_blocking / medium — crates/ironrdp-testsuite-core/tests/server/autodetect.rs:72-98
   All three iterations use send_rtt_request(0) and handle_response(.., 20), so every sample is 20 ms and snap.min_ms == snap.avg_ms. The assertions base_rtt_ms == Some(snap.min_ms) and average_rtt_ms == snap.avg_ms are therefore vacuous with respect to the mapping they claim to pin: swapping the two arguments in netchar_result_rtt(seq, snapshot.min_ms, snapshot.avg_ms) leaves both tests green. The crate-internal twin (crates/ironrdp-server/src/autodetect.rs:280) has the same flaw with a single sample, and the PDU-level wire test only pins the constructor's own argument order, not the server-side mapping. snapshot_reflects_measurements in this same file already uses distinct samples (10/20/30); doing the same here would make the assertions meaningful.
6. non_blocking / low — crates/ironrdp-server/src/server.rs:1472-1475
   The comment attributes a purpose to the spec that the cited section does not carry: per the handoff, 2.2.14.1.5 contains no client-side processing text and 3.2.5.14 says only "Extract the network metrics from the PDU" — no receive-buffer sizing. The repository treats spec-traceable docs as a non-negotiable, and this PR elsewhere removes a spec-inaccurate statement, so introducing a new one regresses the same dimension. The "client does not reply" half is supported. Either drop the citation and present buffer sizing as implementer commentary, or replace it with the actual client action from 3.2.5.14.
7. non_blocking / low — crates/ironrdp-server/src/server.rs
   This PR corrects the "Share Data PDU on the IO channel" misstatement on send_rtt_request, but the identical and more visible claim survives on the public enable_autodetect entry point: "Auto-detect uses lightweight Share Data PDUs on the IO channel." The actual framing is an MCS Send Data Indication on the message channel with a SEC_AUTODETECT_REQ security header (encode_autodetect_request, line 2074). The next sentence, "It supports bandwidth measurement in addition to RTT", is also false — AutoDetectManager measures RTT only, which is precisely why this PR emits the bandwidth-less 0x0840 form. Since server.rs is already touched and the sibling doc is already being fixed, correcting these two sentences keeps the API docs from contradicting each other.
8. non_blocking / low — crates/ironrdp-server/src/autodetect.rs:280-304
   netchar_result_reports_measured_rtt and netchar_result_none_without_samples are added twice — here as crate-internal tests and again in crates/ironrdp-testsuite-core/tests/server/autodetect.rs — with the same assertions and only a 1-vs-3 sample-count difference that changes nothing (all samples are 20 ms either way). This mirrors a pre-existing duplication in these two files, so it is not a new pattern, but it adds two more tests to keep in sync for zero additional coverage. Since build_netchar_result is public API exercised across the crate boundary by the testsuite copy, the internal duplicate is the one that can be dropped.

[Greg Lamberson (glamberson)]

All six threads answered. The round changed the shape of this rather than
patching it, so a summary is worth having in one place.

What it does now: emits only once both RTT and bandwidth are known, paced at one
per second on its own clock rather than once per probe, and withheld unless a
client response arrived since the last result. baseRTT is the session low rather
than the sliding-window low.

Three of those came straight from your findings. The fourth, the session baseRTT,
is where I departed from the reference implementation: krdp takes its minimum
over a 500 ms window, so its baseRTT can rise too, and I think 2.2.14.1.5's
"lowest detected round-trip time" is not ambiguous enough to follow it there.

#1471 is folded in and should be closed. With the both-known gate, this PR alone
could only ever emit the RTT-only form it now declines to send, so keeping them
apart would have meant shipping a PR whose emission never fires. The 0x0840
constructor went with it, since nothing builds that form now; decode still
accepts it.

Two things your review surfaced that were not in it. ironrdp-server sets
[lib] test = false, so the whole inline test module is dead in CI, and four
tests I had added while answering your other threads would never have run. They
are now in ironrdp-testsuite-core and re-verified there. And answering the
comment-accuracy finding caught two more stale comments of my own, both
introduced earlier in this same round.

Title and body are rewritten to match.