HTTP error codes should be considered when error response is malformed in unary requests #810
Description
Trace:
FAILED: Connect Error and End-Stream/HTTPVersion:1/Compression:COMPRESSION_BR/TLS:false/error/null:
actual error code 16 (unauthenticated) does not match expected code 2 (unknown)
---- HTTP Trace ----
request> 0.000ms POST http://.../connectrpc.conformance.v1.ConformanceService/Unary HTTP/1.1
request> Accept-Encoding: br
request> Connect-Protocol-Version: 1
request> Connection: keep-alive
request> Content-Encoding: br
request> Content-Type: application/proto
request> User-Agent: connect-es/1.3.0
request> X-Expect-Codec: 1
request> X-Expect-Compression: 3
request> X-Expect-Http-Method: POST
request> X-Expect-Http-Version: 1
request> X-Expect-Protocol: 1
request> X-Expect-Tls: false
request> X-Test-Case-Name: Connect Error and End-Stream/HTTPVersion:1/Compression:COMPRESSION_BR/TLS:false/error/null
request>
request> 0.408ms message #1: data: 53 bytes
request> 0.409ms body end
response< 0.550ms 401 Unauthorized
response< Content-Type: application/json
response<
response< 0.553ms message #1: data: 4 bytes
response< 0.554ms body end
--------------------
Here, the reference server returns a 401 HTTP status code but returns null body. This expects the error code thrown by the client to be Unknown. This should in fact be Unauthenticated because typically such errors can be returned by any proxy that handles auth, rate limiting etc...
The behavior should be to fallback to the HTTP status code if the error code is malformed in the response.