Fix SslStreamDisposeTest for parallel handshake on Unix

[rzikm]

Fixes #113833.

Previous fix was not enough, lots of opened sockets caused additional failures. This PR changes back to in-memory streams and filters out the InvalidOperationException which happens only in those cases.

[Copilot]

Pull Request Overview

This PR fixes issues related to the parallel handshake on Unix by switching to in-memory streams and refining error filtering.

• Replace TCP streams with in-memory streams
• Update error handling to filter out InvalidOperationException during concurrent disposal

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[wfurt]

It is curious that the memory stream throes InvalidOperationException when NetworkStream does not? Or is that really Invalid access we do in SslStream?

[rzikm]

well, the parallel dispose call disposes the underlying StreamBuffer, causing the InvalidException when attempting to write the next chunk to underlying stream

runtime/src/libraries/Common/src/System/Net/StreamBuffer.cs

Lines 93 to 103 in 41e02e5

	private (bool wait, int bytesWritten) TryWriteToBuffer(ReadOnlySpan<byte> buffer)
	{
	Debug.Assert(buffer.Length > 0);
	Debug.Assert(!Monitor.IsEntered(SyncObject));
	lock (SyncObject)
	{
	if (_writeEnded)
	{
	throw new InvalidOperationException();
	}

Since the StreamBuffer is just some internal helper, it does not distinguish between state where only write side was closed or the entire instance got disposed.

In NetworkStream, we would get ObjectDisposedException or similar

[rzikm]

/ba-g Ci failures are unrelated