core: Gracefully handle GOAWAY frames with unrecognized error codes (v1.82.x backport)

[AgraVator]

Backport of #13035 to v1.82.x.

Fixes #13031.
Discussion: #13026.

When a server or reverse proxy sends an HTTP/2 GOAWAY frame containing an unrecognized or non-standard error code (e.g., Apache HTTP Server 2.4.62's APR_TIMEUP 70007 / AH03069), GrpcUtil.Http2Error.forCode(errorCode) returns null.

On master, GoAwayDisconnectError threw an uncaught NullPointerException when passed a null Http2Error:

java.lang.NullPointerException: Http2Error cannot be null for GOAWAY
    at io.grpc.internal.GoAwayDisconnectError.<init>(GoAwayDisconnectError.java:38)
    at io.grpc.netty.NettyClientHandler.goingAway(NettyClientHandler.java:971)
    at io.grpc.netty.NettyClientHandler$FrameListener.onGoAwayRead(NettyClientHandler.java:1087)

Changes

• In GoAwayDisconnectError, default null error code to GrpcUtil.Http2Error.INTERNAL_ERROR rather than throwing NullPointerException.
  • In accordance with RFC 9113 Section 7 (Error Codes): "Unknown or unsupported error codes MUST NOT trigger any special behavior. These MAY be treated by an implementation as being equivalent to INTERNAL_ERROR."
• Added unit tests in GrpcUtilTest covering GoAwayDisconnectError null and unknown error code fallbacks.
• Added regression tests in NettyClientHandlerTest verifying that unknown GOAWAY error codes cleanly shut down the transport, cancel active streams, and fail new streams with UNAVAILABLE rather than hanging.