missing cleanup of CancellationTokenSource - #4009

Summary

Several CancellationTokenSource (CTS) instances across the driver were created but never disposed, leaking the timer/registration resources they hold. This PR disposes those token sources at the correct point in their lifecycle, and adds the guards needed so that the new disposal does not introduce ObjectDisposedException faults when an object is closed/disposed more than once or concurrently.

Changes

Managed SNI — SsrpClient.netcore.cs

• Wrap the CancellationTokenSource used for parallel SSRP resolution (MultiSubnetFailover) in a using so it is disposed when resolution completes.

SqlDataReader.cs

• Close() and CloseReaderFromConnection() now dispose _cancelAsyncOnCloseTokenSource after cancelling it.
• The source is taken with Interlocked.Exchange(ref _cancelAsyncOnCloseTokenSource, null) so it is cancelled/disposed exactly once. This keeps repeated Close()/Dispose() calls (and the broken-connection cleanup path) safe — a second close sees null and does nothing instead of calling Cancel() on a disposed source.

SqlConnection.cs — reconnect cancellation

• ReconnectAsync now owns its CancellationTokenSource: it is created before the try and disposed (and the _reconnectionCancellationSource field cleared) in the finally, once the token is no longer in use.
• Close() only cancels the reconnect source and lets ReconnectAsync's finally dispose it, avoiding disposal while the reconnect task is still using the token. The Cancel() call is wrapped in try/catch (ObjectDisposedException) to tolerate the race where ReconnectAsync disposes the source concurrently.

SqlCommand.NonQuery.cs / SqlCommand.Reader.cs — reconnect timeout

• In the reconnect continuation, timeoutCts is now disposed on every path (already-completed, success, failure, and cancellation), not just the success path.
• Cancel() is called before Dispose() so the Task.Delay(timeout, timeoutCts.Token) scheduled by SetTimeoutException is released promptly instead of lingering until the timeout elapses.

SqlSequentialStream.cs / SqlSequentialTextReader.cs

• Dispose(bool) now disposes _disposalTokenSource.
• SetClosed() is made idempotent (early-return when already closed). SqlDataReader.CloseActiveSequentialStreamAndTextReader() may call SetClosed() after the consumer has already disposed the stream/reader; without the guard the second Cancel() would throw ObjectDisposedException on the now-disposed source. The first close already cancels and waits for any pending task, so the later call is safely a no-op.

Notes

• CancellationTokenSource.Dispose() is idempotent (per the IDisposable contract), so repeated Dispose() calls are safe; only Cancel()/Token throw after disposal, which is what the added guards protect against.
• All changes are behavior-compatible; no public API changes.

Checklist

• Existing behavior preserved (no public API changes)
• Guards added so disposal does not introduce ObjectDisposedException on double-close/concurrent paths
• Tests added/updated (CancellationTokenSourceDisposalTest — dispose-then-close and double-close paths)