Don't set transfer TCS exception if disconnect exception is null

[jpdillingham]

I don't recall why I created this branch, but these changes seem to make sense so I'm going to merge it.

[jpdillingham]

On second thought, after looking at the unit tests that would cover this, I don't think it makes sense. There's this logic:

                var firstTask = await Task.WhenAny(
                    readTask, // we successfully read all of the data
                    disconnectedTaskCancellationSource.Task, // the connection is disconnected
                    download.RemoteTaskCompletionSource.Task).ConfigureAwait(false);

This sets up a race condition between:

1. The task that's reading all of the data from the connection
2. The TCS that's tripped in the event handler that this PR modifies
3. A TCS supplied by whoever called the DownloadAsync method

If the connection disconnects before either of the other two tasks, the transfer has failed, and we need the disconnectedTaskCancellationSource to throw when we await it so that the proper error handling logic kicks in. If we don't set an exception via SetException(), we'll await that TCS and the logic will proceed as if the transfer had succeeded, which is incorrect.

We deliberately disconnect the connection with download.Connection.Disconnect("Transfer complete"); after the read task successfully completes, and in that case we could hit an unobserved null reference exception in the event handler, which might be the thing I was trying to avoid with these changes originally. It doesn't impact anything other than relieving pressure from the TaskScheduler needing to deal with it.

As far as I can tell, the thing to do here is nothing; everything is already working as intended.