[Foundation] Break out of the delegate when we have canceled a task. Fixes #9132

[mandel-macaque]

This is an interesting issue that happens in the following scenario:

1. A request is performed that will take some extra time to get a
   response or an error.
2. The request is cancelled BEFORE the delegate methods
   DidReceiveResponse, DidReceiveData or DidCompleteWithError and
   called. Yet we have not yet fully canceled the native request. It
   does take some time to do so, that is why we have a
   'NSURLSessionTaskStateCanceling' and not 'NSURLSessionTaskStateCancelled'

The issue happens because the GetInflightData checks if the task has
been canceled. In that method we have the following:

if (inflight.CancellationToken.IsCancellationRequested)
  task?.Cancel ();
return inflight;

The call of the Cancel method in the NSData task has as ripple effect which
is the execution of the following callback:

cancellationToken.Register (() => {
  RemoveInflightData (dataTask);
  tcs.TrySetCanceled ();
});

Which calls:

void RemoveInflightData (NSUrlSessionTask task, bool cancel = true)
{
      lock (inflightRequestsLock) {
              if (inflightRequests.TryGetValue (task, out var data)) {
                      if (cancel)
                              data.CancellationTokenSource.Cancel ();
                      data.Dispose ();
                      inflightRequests.Remove (task);
              }
              // do we need to be notified? If we have not inflightData, we do not
              if (inflightRequests.Count == 0)
                      RemoveNotification ();
      }

      if (cancel)
              task?.Cancel ();

      task?.Dispose ();
}

The above call does call Dispose and Dipose in the inflight data does:

if (disposing) {
    if (CancellationTokenSource != null) {
            CancellationTokenSource.Dispose ();
            CancellationTokenSource = null;
    }
}

If we follow these set of events for example in the
DidRecieveResponse:

[Preserve (Conditional = true)]
public override void DidReceiveResponse (NSUrlSession session, NSUrlSessionDataTask dataTask, NSUrlResponse response, Action<NSUrlSessionResponseDisposition> completionHandler)
{
    var inflight = GetInflightData (dataTask);

    if (inflight == null)
            return;

    try {
            var urlResponse = (NSHttpUrlResponse)response;
            var status = (int)urlResponse.StatusCode;

            var content = new NSUrlSessionDataTaskStreamContent (inflight.Stream, () => {
                    if (!inflight.Completed) {
                            dataTask.Cancel ();
                    }

                    inflight.Disposed = true;
                    inflight.Stream.TrySetException (new ObjectDisposedException ("The content stream was disposed."));

                    sessionHandler.RemoveInflightData (dataTask);
            }, inflight.CancellationTokenSource.Token);

If can happen that, when we get the delegate call to the method, the
request has been cancelled. That means that we are in the precise state
in which we do not longer care about the response BUT we did get a
infligh data reference.. that HAS BEEN DISPOSED!!! this later gives a NRE
in several places.

The correct way is to return null from the GetInflighData method if we
have been cancelled, this makes sense because if we cancelled we do not
care about the execution of any of the methods that required the data
since it has been disposed!

fixes #9132

[spouliot]

Let's get confirmation it fix the customers issues before backporting to release branches (since it looks unlikely to get a [unit] test for this)

[spouliot]

ergo ? we're now using latin for comments :)

[mandel-macaque]

We are that posh :)

[spouliot]

typo -> dele[g]ate

[mandel-macaque]

@spouliot I'll trigger a pkg build for this.

[monojenkins]

Build failure
❌ Build failed or was aborted

✅ Provisioning succeeded
🔥 Build failed 🔥

[monojenkins]

Build failure
✅ Provisioning succeeded
✅ Build succeeded
✅ API Diff (from stable)
🔥 Failed to compare API and create generator diff 🔥
    Failed to build src/
    Search for Comparing API & creating generator diff in the log to view the complete log.
✅ Test run succeeded

[mandel-macaque]

Watch issues are known and have been fixed on #10235

[monojenkins]

Build failure
✅ Provisioning succeeded
✅ Build succeeded
✅ API Diff (from stable)
🔥 Failed to compare API and create generator diff 🔥
    Failed to build src/
    Search for Comparing API & creating generator diff in the log to view the complete log.
✅ Test run succeeded

[ahhassan3]

Is there any estimate on when will this fix be released ? It's causing us many crashes

[mandel-macaque]

@ahhassan3 we have not landed it because we did not had customers confirming the fix.

[ahhassan3]

@mandel-macaque This bug is somewhat difficult to reproduce on demand but we have ad over 70 counts of crashes from the customer who use our app because of this issue. I saw that you have merged it on to the main code branch, do you know when the xamarin.forms nuget will be updated with this fix in it. Thank you