Fix deadlock in SftpClient.UploadFile upon error

[Rob-Hague]

When the server returns an error during UploadFile, unless the response is quick enough that the exception is captured before SftpSession.RequestWrite finishes...

SSH.NET/src/Renci.SshNet/Sftp/SftpSession.cs

Lines 941 to 944 in d08c4aa

	if (exception is not null)
	{
	throw exception;
	}

... then the error is not propagated because SftpClient.UploadFile does not have any handling for failure (StatusCode != Ok):

SSH.NET/src/Renci.SshNet/SftpClient.cs

Lines 2475 to 2480 in d08c4aa

	_sftpSession.RequestWrite(handle, offset, buffer, offset: 0, bytesRead, wait: null, s =>
	{
	if (s.StatusCode == StatusCodes.Ok)
	{
	_ = Interlocked.Decrement(ref expectedResponses);
	_ = responseReceivedWaitHandle.Set();

This causes deadlock because the expectedResponses is only decremented in this path and will never hit zero.

The first commit is the fix for the deadlock (handle failure codes in UploadFile). The second commit tidies up SftpSession.RequestWrite to fix the racy exception behaviour as pointed out in #1640 (the exception handling only makes sense here when given a wait handle).

I wrote an ugly test for this (Rob-Hague@9a7526a) but it only fails on develop after cherry-picking the second commit because the test is single-threaded so we encounter the race in RequestWrite.

closes #957
closes #1640

[drieseng]

Can you reproduce this using an integration test?