fix: don't let one unreachable server stall the whole listener

[ralfbecher]

The problem

TDSListener.AcceptConnection created the TDSConnection inline and only re-armed
BeginAcceptTcpClient after it returned:

new TDSConnection(_service, this, readClient, ForwardTo);   // dials the far server, blocking
...
_tcpListener?.BeginAcceptTcpClient(AcceptConnection, _tcpListener);

The constructor dials the far server with a blocking Connect. When that server swallows SYNs
rather than refusing them, the dial runs the full OS retry sequence — ~135 s on Linux — and for
that entire time there is no accept in flight, so every client waits in the backlog.

Seen in production against a legacy SQL Server that is blackholed for part of each night: the
proxy accepted one connection per 135 s, for all clients, until the far side came back.

Why keep-alive (#6) does not cover it

Keep-alive detects a peer that vanishes from an established connection. Here no connection is
ever established — the failure is in the dial itself.

Changes

1. Re-arm the listener before setting up the connection. A slow or dead far server no longer
   serializes accepts. Failures during accept itself return without constructing anything.

2. Bound the dial at 10 s (ConnectWithTimeout) instead of leaving it to the OS SYN retries,
   so a thread is not parked for minutes per attempt.

3. Roll back construction when the dial fails (AbandonBeforeConnected). service.Stopping += service_Stopping is taken before the dial and is what keeps a TDSConnection alive, so a
   failed attempt lingered — still holding the accepted client socket, still counted in
   ActiveConnectionCount — until the service stopped. This is the origin of the hundreds of

   ERROR TDSProxy.TDSConnection - Error closing inside stream for connection from 127.0.0.1:NNNNN
   System.NullReferenceException: ... at TDSProxy.TDSConnection.System.IDisposable.Dispose()
   

   at shutdown: one per stranded attempt, _insideStream never assigned. It is null-guarded now
   as well, matching the _insideSSL?.Close() next to it.

Verification

dotnet build -c Release against dotnet/sdk:6.0-bullseye-slim (the image this is deployed
from): clean, 0 warnings.

The behavioural check is at the far end: with an unreachable server, the log must show a failure
per attempt with Accepted connection entries continuing at the clients' own pace, instead of one
accept per connect-timeout.

🤖 Generated with Claude Code