FluentFTP: GetListing blocking with no timeout

@robinrodricks Currently for .NET Core the synchronous call is using stream.ReadAsync() on the stream instead of the sync version stream.Read(). Async read calls (.ReadAsync or .BeginRead (which isn’t available in .NET Core afaik)) on a stream will never use the ReadTimeout. So if the server doesn’t send anything back but keeps the connection alive FluentFTP is stuck on this call forever until the socket/stream closes. For the sync version just using .Read instead will use the Timeout and doesn’t need a call to .Result

In general using .Result is not the prefered way to call async code synchronously (which should be prevented cause of potential deadlocks anyway) cause it will for example not Unwrap Exceptions see: https://stackoverflow.com/questions/17284517/is-task-result-the-same-as-getawaiter-getresult

The async part is a bit more complicated cause we should use the Async calls there. There is a general issue with CancellationTokens in FluentFTP. The Async calls should pass a global CancellationToken down the line to the ReadAsync call. Currently for the workaround I use another Task with Task.Delay and check if the timeout task is the first one that finished. If it is, then I force close the stream. That will cause the “real” task to finish with an IO Exception and causes it to get unstuck. I will throw a timeoutexception instead of awaiting the original Task.

I’ve made a first attempt to pass cancellation tokens from every method down to ReadAsync. There are a few cases where this is not possible so I made a OnCancled function that checks for the cancelationtoken being triggered and then closing the stream/socket. https://github.com/WolfspiritM/FluentFTP/commit/393a9202dbc2fbd0db825da693dfdaa4c2f9af15 It’s a big change and I’m not sure if I got everything…but I think it’s the cleanest way cause that’s how ReadAsync is supposed to work. I will take a look at it more later. I did change a few method invocations so the CancelationToken is at the end…so I don’t think it’s a good thing to include in a minor update.

	// GetListing with Timeout of 1000 milliseconds
	var cts = new CancellationTokenSource(1000);
	var test = await cl.GetListingAsync(cts.Token);

	foreach (var item in test)
	{
		Console.WriteLine(item.FullName);
	}

The question is if we should combine that token with another one that is using ReadTimeout within the ReadAsync method so we are using the global ReadTimeout variable?!