Avoid "Maximum active streams violated for this endpoint" at the client level

[idelpivnitskiy]

Motivation:

In #1307 we changed LoadBalancedStreamingHttpClient to not close the
connection on cancel for HTTP/2 protocol, because our existing API does
not expose methods for closing h2 stream instead of h2 connection.
Instead, we had to prematurely mark the request as finished, because
in case of cancellation, there is no guarantee we will receive a terminal
signal on the response. Also, the stream is not aware of
LoadBalancedStreamingHttpConnection API and therefore it can not mark
the request as finished when it closes the stream.
That change significantly increased the probability users see
"Maximum active streams violated for this endpoint." Even though it's a
RetryableException, it creates pain and still may pop up after
auto-retry strategy used all attempts.

Modification:

• Introduce OwnedRunnable that can be passed to the transport layer
  with the request object;
• Add pkg-private StreamingHttpRequestWithContext wrapper which
  delivers OwnedRunnable to the transport;
• Generate that OwnedRunnable in LoadBalancedStreamingHttpClient;
• LoadBalancedStreamingHttpClient marks the request as finished only
  if it owns OwnedRunnable;
• If h2-transport takes ownership of the OwnedRunnable,
  LoadBalancedStreamingHttpClient is not responsible for marking the
  request as finished anymore;
• Add tests to verify the fix;

Result:

HTTP/2 requests marked as finished only before they reach transport or
only after the stream closes.

[Scottmitch]

few comments then lgtm for near term workaround.

[Scottmitch]

do we need to create the new exception type, or can we just use CancellationException and ThrowableUtils.unknownStackTrace?

[idelpivnitskiy]

if we don't override fillInStackTrace(), the Throwable ctor will invoke it and fill in the stacktrace which ThrowableUtils.unknownStackTrace will override later => useless expensive operation.