Let an idle CID update past a stale ping-pong guard

Misc.IdleDestCidChange failed both kernel BVTs, and a bisect settled where
it came from: 1cee9be, the per-path MTU probe, fails 2 of 4 kernel jobs
while its parent 2674a37 passes 4 of 4. Three other control refs pass 12
of 12 between them. It never reproduces on Linux.

What the ETL trace shows. RetirePriorTo is not a decision, it is
arithmetic -- Sequence + 1 - SourceCidLimit, with the limit at 4 -- so
once either side advertises a source CID at sequence 4 or above the peer
is forced to replace its destination CIDs. That runs
QuicPathIDReplaceRetiredCids, which raises Path->InitiatedCidUpdate and,
unlike QuicPathIDRetireCurrentDestCid, does not count the update. The flag
is cleared in exactly one place, on a peer CID change, which need never
come. The connection then goes quiet, and the idle update in QuicSendFlush
is refused by !Path->InitiatedCidUpdate for the rest of the connection's
life.

The flag stops a change of ours and the peer's answer to it from
ping-ponging, so it is wanted while an answer might still arrive. Nothing
has been sent or received for the whole idle interval by the time this
check runs, so anything pending is long over and the flag is stale. It is
cleared here rather than consulted. Behaviour during an active exchange is
unchanged.

Not the earlier theory. I first blamed Send->LastFlushTime being stamped
by a probe that gave up, and fixed that in 0419a77. That fix is right on
its own terms -- a probe that sends nothing should not reset the idle
clock -- but it was not this, and it did not help.

Local: IdleDestCidChange 20/20, targeted 40/40, 172 in the path sweep and
1443 in the broad sweep, clang-tidy 21 clean. Since this does not
reproduce on Linux, the real check is the kernel BVT, twice -- one 4/4 run
leaves about a 6% chance of missing a 50% failure.

Author: masa-koz

src/core/send.c

@@ -1966,8 +1966,25 @@ QuicSendFlush(
     //
     if (Connection->Settings.DestCidUpdateIdleTimeoutMs != 0 &&
         Send->LastFlushTimeValid &&
-        CxPlatTimeDiff64(Send->LastFlushTime, TimeNow) >= MS_TO_US(Connection->Settings.DestCidUpdateIdleTimeoutMs) &&
-        !Path->InitiatedCidUpdate) {
+        CxPlatTimeDiff64(Send->LastFlushTime, TimeNow) >= MS_TO_US(Connection->Settings.DestCidUpdateIdleTimeoutMs)) {
+        //
+        // InitiatedCidUpdate is not consulted here, and is cleared instead.
+        //
+        // It exists to stop a change of ours and the peer's answer to it from
+        // ping-ponging: while it is set, a peer CID change clears it rather
+        // than provoking another change from us. That only needs to hold for
+        // as long as an answer might still be coming, and nothing has been
+        // sent or received on this path for the whole idle interval, so
+        // anything still pending is long over.
+        //
+        // Leaving it set here is what broke Misc.IdleDestCidChange. It is also
+        // raised by QuicPathIDReplaceRetiredCids, for a replacement the peer
+        // forced on us with retire_prior_to -- and that one is only ever
+        // cleared by a peer CID change, which need never come. A connection
+        // that took a forced replacement and then went quiet could not do an
+        // idle update again for the rest of its life.
+        //
+        Path->InitiatedCidUpdate = FALSE;
         if (QuicConnRetireCurrentDestCid(Connection, Path)) {
             Path->InitiatedCidUpdate = TRUE;
         }