Implements SslStreamProxy write synchronization with SemaphoreSlim

[JAZDaddy]

Following feedback on dotnet#579 (dotnet#579 (comment)), implemented synchronization using SemaphoreSlim to avoid race conditions (and the expected recurrence of the original SslStream WriteAsync failure) on completion of _currentTask.Wait. We've been able to scale up the TVP size on tests above 1MM rows without issue and get past this critical, release-blocking error in our Docker-based .NET Core solution with this implementation.

[DavoudEshtehari]

Hi @JAZDaddy

Thank you for the suggested code and for sharing the investigation results.
We already have an in-progress change. The main concern is the order of requests that might be changed in a load condition. We have a plan to back to it for further investigation.
Please, don't stop sharing your thoughts.

[JAZDaddy]

@DavoudEshtehari Thanks for your feedback; I'd be interested to hear the direction this is going in order to deal with the ordering concern. We're likely to hold onto this SemaphoreSlim for our own use in the interim since we're dead in the water without it.

I apologize in advance if what follows is incredibly simplistic...

Coming to this without the context you're immersed in, it's hard to get a handle on whether the SslStream's (sensible) single-writer demand is the core issue (thus synchronizing in SslStreamProxy as you have) versus having simultaneous callers requesting writes in the first place. It seems like the async paradigm flies in the face of the underlying assumptions of single-threaded synchrony in TDS. It's almost like each writer really wants to have the stream to itself until its batch is complete instead of viewing the stream as a simple common resource. If that's the case, it seems that the message, rather than the packet, is the more accurate locking granularity. Again, apologies if that's not even close...

[DavoudEshtehari]

Hi @JAZDaddy

FYI: Proposal extended and reworked in #796
Feel free to review/test it.