[Bug] Respect client timeout even after response headers are returned

[JoshLove-msft]

Since we use the HttpCompletionOption.ResponseHeadersRead option in HttpClientTransport, the HttpClient timeout will not apply after the response headers are returned.
This means that if the body of the response never returns for some reason, the client will block indefinitely.

Describe the solution you'd like
Issue #9289 requested a ClientTimeout property in ClientOptions. Once we add this, one idea would be to respect the property even after the header is returned. Specifically, RetriableStream could respect this timeout and throw a TimeoutException if we pass the timeout. A problem with this approach would be that large files would likely timeout, so a better approach would be to either use the same timeout (or a different timeout value) to mean how long to wait before throwing when data has stopped returning, or go by the rate that the data is being read and throw if we fall under a certain threshold. The service has a 2MB/minute minimum threshold before throwing: https://docs.microsoft.com/en-us/rest/api/storageservices/setting-timeouts-for-blob-service-operations

I'm not sure if there are other scenarios not involving RetriableStream where this indefinite blocking can occur, but if there are we should address those to.

[mikeharder]

@JoshLove-msft: Should this be fixed by #10128? If so, can we try to re-enable the tests?

[JoshLove-msft]

I think so, we should give it a try.

[AlexGhiondea]

@JoshLove-msft is this still applicable? If not, please close this.

[JoshLove-msft]

This was fixed in #10169
Closing