Allow server to cancel when deadline expires

[jhump]

This makes some assertions for timeout cases a little more lenient. The tests previously asserted that a server would return a "deadline exceeded" error when the client's deadline expires. However, not all gRPC servers behave this way. The gRPC Go reference implementation was recently updated to sometimes just cancel the stream instead of sending back an error response. This doesn't seem unreasonable, so instead of updating the "known failing" list of cases for the grpc-go server, this PR makes this behavior allowed (which means it will be allowed in any other implementation-under-test, too).

The test case structure lets us define other acceptable error codes for test cases, however we don't actually want to add "canceled" as generally acceptable for these tests. It's really only acceptable for the server (clients should always report "deadline exceeded" for these cases). So we need to update the test assertions logic to get that level of nuance.

If you look at the latest commit on main as well as all open Depend-a-bot PRs, you'll see that CI is red on these commits because of this behavior -- it seems like one (out of five) of the timeout tests fails with each run. Interestingly, they normally pass (I've yet to even see a run where more than one failed; they seem to always pass when I run the suite locally). The actual failures observed so far have been in "unary", "client-stream", and "half-duplex/bidi-stream" tests (not yet observed for "server-stream" or "full-fuplex/bidi-stream" tests).

The behavior causing CI to be flaky/red was introduced in #993, which pulled in the latest grpc-go, v1.72.0, which included grpc/grpc-go#8071 (which is the culprit for the new behavior).

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	May 13, 2025, 1:21 PM