Fix race condition in HttpClient timeout handling and GetAsync_ContentCanBeCanceled

[stephentoub]

Fixes #44003

There are three issues here.

Two tests issues:

1. When the client times out, it could do so while the server is still reading the request or sending the response, in which case the server can fail and cause the test to fail. The server failure needs to be ignored.
2. when the client times out, it could do so before it even initiates the request, in which case the test would hang while the server waits indefinitely for a request that'll never arrive. The server waiting needs to factor in the client's completion.

And one product issue:

1. The timeout handling we added in .NET 5 has a race condition that can, in extreme conditions (e.g. a unit test trying to force the interleaving) result in us not throwing the appropriate TimeoutException. There are two different timer mechanisms used, the one based on Timer inside of CancellationTokenSource, and then the use of Envrionment.TickCount64 to track how much time has progressed. Their quantums are different, so it's possible for the timer to fire due to the timeout expiring but Environment.TickCount64 not ticking over, at which point we'll read it and determine that the cause of the cancellation wasn't for a timeout. The fix is to use the pending requests token source to check whether it or the timeout occurred, rather than using the time elapsed to determine which of the two occurred.

cc: @geoffkizer, @wfurt, @alnikola

[wfurt]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[wfurt]

LGTM