Fix flaky test

[gjcairo]

HTTP2TransportTLSEnabledTests/testServerFailsClientValidation would rarely fail with a CancellationError being unexpectedly thrown.

I believe this happens because when triggering a graceful shutdown on the server, the quiescing event is translated into a cancellation error if there are connections still open. However, whether this error is surfaced seems to have to do with the timing of both the client and the server shutting down.

I have refactored the test to use nested withGRPCServer/withGRPCClient with-style methods instead, as this should eliminate timing issues.

[glbrntt]

This refactor makes sense but I'd like to understand the problem a bit more first to make sure we're not just working around it.

I believe this happens because when triggering a graceful shutdown on the server, the quiescing event is translated into a cancellation error if there are connections still open.

What function is surfacing that error?

[gjcairo]

CommonHTTP2ServerTransport/listen does a serverChannel.executeThenClose where we iterate over the channel's inbound stream. This for-await loop throws CancellationError and we don't handle it.

[glbrntt]

CommonHTTP2ServerTransport/listen does a serverChannel.executeThenClose where we iterate over the channel's inbound stream. This for-await loop throws CancellationError and we don't handle it.

What triggers the cancellation?

[gjcairo]

In the current implementation we have a discarding throwing task group with one task running the server and the other running the client requests. In this type of task group, when one task throws, the others are cancelled. In rare instances where the client throws, the server task would get cancelled before the server is gracefully shut down. This would trigger the CancellationError to be thrown from the server.