apply_full_topology computed peer class ids inline while inspect_and_diff computed them
through expected_peer_class_map. Two implementations of the same contract, and
apply_full_topology ends by calling inspect_and_diff to verify its own work - so a
divergence between them would surface as verify-after-apply failing on a topology that had
just been applied correctly, with a reason pointing at class mapping rather than at the
real cause. Apply now uses expected_peer_class_map, which makes it structurally impossible
for the two sides to disagree.
Behaviour is identical. Both paths assign class_start_id + index over peers in slice order,
and discover_peers hands them over sorted lexicographically and deduplicated. Iterating the
resulting BTreeMap walks the same keys in the same order, so the emitted tc commands and
their class ids are unchanged; only the loop source moved.
expected_peer_class_map is now the single source of truth for the class-id contract and
gained the tests it never had: lexicographic ordering (10.8.1.10 before 10.8.1.2, the
production contract that must not silently become numeric), a non-default class_start_id,
u16 overflow, and the empty peer list.
Found while splitting traffic.rs; kept out of that commit to keep the move reviewable.
cargo test --workspace: 114 + 4 passed, four new. clippy -D warnings clean.
founder
7254ebe9e4