Identify retryable Http2Exception(s) generated by netty

[idelpivnitskiy]

Motivation:

HTTP/2 codec may throw an exception when it creates a stream in some cases:

• When there is a concurrency between closing the parent h2 connection and
  creating a new stream;
• When stream IDs are exhausted for this endpoint;
• When maximum active streams violated for this endpoint;
  In all this cases it's safe to retry the request because we do not start
  writing it on the wire. When parent connection is closing concurrently, we
  won't hit this error again because it will be marked as "closing" and LB
  won't select this connection again.

Modification:

• Wrap Http2Exception(s) with Http2Error.REFUSED_STREAM as retryable;
• Wrap Http2NoMoreStreamIdsException as retryable;

Result:

HttpClient will automatically retry recoverable HTTP/2 exceptions.

[Scottmitch]

There is code in AbstractH2DuplexHandler that also checks for REFUSED_STREAM and throws a Retryable exception. is there a way to have these two areas share code so the relationship is more clear and less likely to miss cases in the future (e.g. if we want to add ENHANCE_YOUR_CALM or others)?

[idelpivnitskiy]

I thought about it but did not found a good way to do that because in AbstractH2DuplexHandler it handles a user-event and created a new exception based on that event when here we intercept write failures. May give another round of thoughts after the release.

[idelpivnitskiy]

Follow-up with the fresh head :)
#1318