Changes

Reapply "Release all waiting processes when destroying a socket (fixes #15975)"

This reverts commit f5df5966bd73d05bc04806d2f8735baa4b1783cb.

Signal each Semaphore only once to avoid dependency on #signalAll

This should be sufficient, as multiple processes trying to read or write at once will result in undefined behavior anyway as their data gets all mixed up together.
		

Access semaphores directly from their instance variables rather than through accessors

This was already sometimes the case, and makes sense--these are private implementation details that really shouldn't be exposed to the outside world at all.
Also refactor to make it clearer that #waitForData is strictly a degenerate case of #waitForDataFor:...--the loop structure is identical, just without the timeout-related bits.

Add delay and update comment in #testFlushOtherEndClosed to prevent transient failure

Add wait in #testNextPutAllFlushOtherEndClosed similar to #testFlushOtherEndClosed

Actually, extract a helper as the first part of each test is identical.

Ensure we actually fill the TCP send buffer in #testFlushLargeMessageOtherEndClosed

Linux default is enormous (~2.5MiB), while Windows is only 65KiB. Attempt to standardize on this small buffer, but make sure we exceed the *actual* buffer size, as Linux (again) refuses to set a buffer size below 416KiB.

Skip SocketStreamTest>>testFlushLargeMessageOtherEndClosed on Windows

Fails due to Windows accepting arbitrarily large messages--much larger than the TCP send buffer--in a single send(2) call, preventing #waitForSendDone... from being called during the send process. Not sure why but this is not a regression, just strange behavior revealed by the new test.

Clarify the purpose of the return value from #waitForSendDoneFor:...

Also, no need to actually store a `sendDone` temp, if we reach the end of the method we know it is true.