Remove custom cancellation token handling code, rely on Stream.ReadAsync to handle it instead

[danzel]

Fixes #131

I've tried tracing this code back in git history to figure out why this override exists. Previously it had a comment:

We ensure that this service can be closed ASAP with the help of a Task.Delay.

Does Stream.ReadAsync take meaningfully longer to cancel than using a TaskCompletionSource?.

If there is a reason it is this way, we can probably keep the behaviour and observe the result so that the we don't end up with an UnobservedTaskException later, it'll be a bit clunky though.

[fubar-coder]

It might've been a problem in an older version of .NET (Core), that the stream would only be cancelled when new data arrives or some timeout occurs.

[danzel]

Is this something we need to support or test? If you can let me know what needs manual testing I can hopefully do it.

[fubar-coder]

I thought that I read in an article (MS blog post), that they fixed it in .NET Core 3.1, but I might be misremembering it. You can read more about it here:

https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#file-i-o

[ite-klass]

When I apply this change I can not connect via FTPS anymore (both explicit and implicit).

FileZilla client log:

Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/"
Command:    TYPE I
Response:   200 Binary transfer mode active.
Command:    PASV
Response:   227 Entering Passive Mode (127,0,0,1,195,49).
Command:    MLSD
Response:   150 Opening data connection.
Error:  GnuTLS error -110 in gnutls_record_recv: The TLS connection was non-properly terminated.
Status: Server did not properly shut down TLS connection
Error:  Could not read from transfer socket: ECONNABORTED - Connection aborted
Response:   226 Closing data connection.
Error:  Failed to retrieve directory listing