Ioxide engine: adapt to the next ioxide release (IdleTimeoutMs rename, drop the raw shutdown calls)

[MDA2AV]

The ioxide engine pins ioxide 0.14.239. The first ioxide release after 0.15.251 will include MDA2AV/ioxide#246, which needs a few changes here. Checked by building Engine/Ioxide against ioxide's current main.

1. Build break: IdleTimeoutMs was renamed to ReadTimeoutMs

ioxide#246 renamed the option on both transports. These are the only two compile errors:

• Engine/Ioxide/Infrastructure/Server.Tcp.cs:35: TcpOptions.IdleTimeoutMs → ReadTimeoutMs
• Engine/Ioxide/Infrastructure/Server.Quic.cs:88: QuicOptions.IdleTimeoutMs → ReadTimeoutMs

With both renamed, the engine builds against ioxide main on net10.0 and net11.0.

The meaning changed too, so the doc on TcpTransportOptions.IdleTimeoutMs in EngineOptions.cs should change, and possibly its name:

• Before: close a connection that has neither received nor sent anything for this long.
• Now: the clock only runs while the connection is waiting on its client, with a read parked and nothing being sent. The server's own sends restart it, and time the handler spends working does not count. A slow handler no longer gets its connection cut; an idle keep-alive or websocket still does.
• The websocket advice there still holds: set it above the ping interval. A ping from either side restarts the clock.
• QUIC works the same way: the clock only runs while the client owes the next move, and ioxide pings to keep the connection alive while a response is still being produced.

2. Delete the raw shutdown(2) calls

TcpDriver.cs:52 and TcpDriver.cs:181 call shutdown(conn.ClientFd, SHUT_WR) through a LibraryImport, and each is followed by conn.DecRef(). Since ioxide#246, DecRef() sends that FIN itself. It waits for any send still in flight, and never targets an fd the reactor has already closed. So both calls and the LibraryImport can simply go.

The raw call is also the riskier version:

• ClientFd isn't the engine's to shut down. After a reactor teardown that number can belong to another socket.
• A FIN while a send is still in flight cuts the response short.

If the engine ever needs a FIN while keeping the connection (Connection: close with the handler still reading), MDA2AV/ioxide#262 adds TcpConnection.ShutdownWrite() for that. These two sites don't need it.

3. Optional: the RecvQueueEntries default

TcpTransportOptions.RecvQueueEntries defaults to 64 (EngineOptions.cs:56). At 64, a connection whose handler is slow to read can overflow its receive queue, and the reactor then drops data and closes the connection. MDA2AV/ioxide#257 (pending) raises ioxide's own default to 4096 and reports an overflow as an error rather than a clean EOF. Consider following ioxide's default.

[MDA2AV]

Update: ioxide 0.16.268 and 0.16.281 are both out, and both include MDA2AV/ioxide#246. Building Engine/Ioxide against 0.16.281 (it pins 0.15.251 today) gives the two IdleTimeoutMs errors above, plus two new ones from MDA2AV/ioxide#274:

• Engine/Ioxide/Protocol/Drivers/Tcp/Http2Driver.cs:72: CS0407, Http2ResponseWriter.FlushAsync() has the wrong return type
• Engine/Ioxide/Protocol/Drivers/Quic/Http3Driver.cs:70: CS0407, Nghttp3ResponseWriter.FlushAsync() has the wrong return type

That PR changed the streamed writers' FlushAsync from ValueTask to ValueTask<FlushResult>, so a flush can report a peer that has gone (IsCompleted), as the HTTP/1 pipe writer already does (MDA2AV/ioxide#269). Both drivers pass writer.FlushAsync where a Func<ValueTask> is expected, and that no longer converts.

This version builds on net10.0 and net11.0: take Func<ValueTask<FlushResult>> in StreamedResponder.WriteBodyAsync and StreamedSink, and throw ConnectionClosedException on a completed flush, the same way Http1WriterStream.FlushAsync does:

// StreamedSink.FlushingStream
public override async ValueTask WriteAsync(ReadOnlyMemory<byte> buffer, CancellationToken cancellationToken = default)
{
    _target.Write(buffer.Span);
    _written += buffer.Length;

    await FlushOrThrowAsync();
}

public override Task FlushAsync(CancellationToken cancellationToken) => FlushOrThrowAsync().AsTask();

private async ValueTask FlushOrThrowAsync()
{
    if ((await _flush()).IsCompleted)
    {
        throw new ConnectionClosedException();
    }
}

The other API change in 0.16.281 doesn't affect the engine. MDA2AV/ioxide#275 removed QuicEngine's maxSendRetentionBytes parameter, which moved to QuicOptions.SendRetentionBytes, and Server.Quic.cs doesn't pass it.

MDA2AV/ioxide#257 and MDA2AV/ioxide#262, mentioned above as pending, are in 0.16.268 as well.