Test that servers reject malformed timeout headers

[stefanvanburen]

The deadline suites send well-formed connect-timeout-ms and grpc-timeout headers, and the reference server checks what clients send, but no server case sends a malformed one. A server that passes the header to a lenient integer parser, or lets the parse error escape, accepts a timeout the protocols don't allow or answers with an unknown server error. connect-py did both (fixed in connectrpc/connect-py#351), and the current suites pass either way.

Related: #1141 and #1142, which cover other malformed requests.

I have the cases on a branch: main...stefanvanburen:conformance:svanburen/invalid-timeout-headers

Cases

Unary requests to the Connect, gRPC, and gRPC-Web server suites:

• invalid-timeout: connect-timeout-ms: 10s for Connect, and grpc-timeout: 10x (an unknown unit) for gRPC and gRPC-Web.
• negative-timeout: grpc-timeout: -1m for gRPC and gRPC-Web.

All expect CODE_INVALID_ARGUMENT, which is what connect-go returns. The gRPC and gRPC-Web cases also allow CODE_INTERNAL, since the gRPC spec doesn't name a code and grpc-go uses internal.

A negative connect-timeout-ms belongs here too, but the reference server is built on connect-go v1.20.0, which accepts it (connect-go fixed this on main in connectrpc/connect-go#982). The branch leaves that case out until the reference server moves to a connect-go version with the fix.

Results on the branch

• Reference server: 19 of 19 variants pass.
• grpc-go: all 6 gRPC and gRPC-Web variants pass, with internal.

Happy to open a PR from the branch if this looks right.