quic: a reactor shutting down frees every connection without telling the peer

[MDA2AV]

Every death path in the QUIC engine was funnelled through Teardown() earlier in this release, so the peer always hears a CONNECTION_CLOSE. One path cannot use it, and it is the one that ends every connection at once: reactor shutdown.

TeardownQuic evicts by removing first and notifying second (src/ioxide/Reactor/Transport/Quic/Reactor.Quic.cs:327):

foreach (QuicConnection conn in _quicSweepScratch)
{
    QuicRemoveConnection(conn);
    conn.OnEvicted(QuicEvictReason.ReactorShutdown);
}

QuicRemoveConnection frees and zeroes the transport-owned peer address on its way out (:229), and QuicConnection.Send is a no-op without one (src/ioxide/Connection/Quic/QuicConnection.cs:119):

if (PeerAddr == 0)
{
    return;
}

So by the time OnEvicted runs there is nothing to send to. QuicEngineConnection.OnEvicted calls Destroy() directly, and it could not do otherwise: routing itself through Teardown would build a CONNECTION_CLOSE and then drop it on the floor.

The idle-sweep case at :251 is the same shape and is correct as it stands. RFC 9000 section 10.1 discards an idle connection silently, and the peer is by definition not listening. Shutdown is different: it is an immediate close, and section 10.2 says an immediate close is signalled with a CONNECTION_CLOSE frame.

What a peer sees today is nothing at all. It keeps a connection open against a server that has gone, until something else reclaims it - and between two ioxide endpoints there is nothing else, because the shim leaves max_idle_timeout unset, so the negotiated idle timeout is disabled (RFC 9000 section 10.1: the effective value is the minimum of the two advertised non-zero values, and neither side advertises one). The client's own transport sweep is the only backstop, which is a local timer rather than a protocol event the application can distinguish from a network partition.

The seam already exists and is unused: OnEvicted takes a QuicEvictReason (QuicConnection.cs:54) and QuicEngineConnection ignores it, so the two cases are already told apart at the call site and simply not acted on differently.

The fix is a reordering in the protected core, which is why this is filed rather than changed. In TeardownQuic only, notify before removing:

foreach (QuicConnection conn in _quicSweepScratch)
{
    conn.OnEvicted(QuicEvictReason.ReactorShutdown);   // may still Send
    QuicRemoveConnection(conn);
}

QuicEngineConnection.OnEvicted then routes the shutdown case through Teardown(farewell) and keeps calling Destroy() directly for IdleTimeout. Double removal is already safe - QuicRemoveConnection gates its release on _quicConnSet.Remove(conn) returning true, so the second call from inside Teardown is a no-op - but the ordering swap is the part that needs a decision, since it means user code (OnEvicted is a public virtual) runs while the connection is still routable and still in _quicConnSet.

Worth deciding alongside it: whether the farewell should carry an application code (Close(0), H3_NO_ERROR for an h3 server) or a transport NO_ERROR, and whether a shutdown should wait for those datagrams to leave the ring before the reactor stops - today TeardownQuic runs during teardown and nothing flushes afterwards.

Found by the second-round TLS review; verified by reading the eviction order rather than observed on the wire, because no test asserts that any teardown path puts a CONNECTION_CLOSE on the wire at all.

[MDA2AV]

Correction to the fix shape above: reordering OnEvicted before QuicRemoveConnection is necessary but not sufficient, and anyone who does only that will find the farewell still never reaches the wire.

TeardownQuic is called from Reactor.Teardown(), which runs after the event loop has exited (src/ioxide/Reactor/Reactor.Runner.cs:84-88):

CloseTcpListeners();
TeardownQuic();
CloseUdpFds();
CloseAcceptedTcpSockets();

Two consequences. A UdpSendTo from there only queues an SQE, and there is no loop left to submit it. And CloseUdpFds() closes the socket two lines later regardless. So the datagram is built, queued, and thrown away with the ring.

A working fix needs all three of: the peer address still live when OnEvicted runs (the reorder), the farewell actually submitted rather than queued (an explicit submit, or a direct sendmsg bypassing the ring), and both completed before CloseUdpFds().

This is now covered by a failing test, committed as runner.Pending so the suite stays green until it is fixed and fails the moment it is:

PEND  quic: a reactor shutdown tells its peers instead of leaving them to time out
      (issue #195 - OnEvicted only frees the connection, and the transport has already run
       QuicRemoveConnection by then, which zeroes the peer address Send needs)

Run as an ordinary test it reports what the peer actually saw:

the peer was left to time out: 8 datagrams arrived after the shutdown and none was a CONNECTION_CLOSE

The detector is the peer's own ngtcp2 rather than packet parsing: a received CONNECTION_CLOSE puts the client into the draining state, so iq_conn_read returning NGTCP2_ERR_DRAINING is the peer reporting that it was told. The test carries its own receive-only client for that, because the shared test client discards that return value.

Three sibling paths were checked at the same time and are correct - an application Close, the send-retention backstop, and the idle sweep, which is silent on purpose per RFC 9000 section 10.1. That last one is worth knowing before fixing this one: OnEvicted ignores its QuicEvictReason entirely, so a fix that simply makes OnEvicted send a farewell would also make the idle sweep start announcing itself, which is wrong. All three are now pinned as passing tests, so that mistake would be caught.