proxy/server: finish the RPC when the client half-closes

[sfc-gh-pkowalewski]

What is wrong

When the request channel closes, dispatch calls ClientCloseAll and returns straight away, which leaves doneChan without a reader. Any target stream that finishes after that point blocks forever trying to report itself, so its wg.Done never runs, TargetStreamSet.Wait never returns and Proxy never returns.

The RPC therefore only ends when the client disconnects, and the status it reports is whatever the dead transport gives back. In practice that means almost every proxied call finishes as Unavailable: transport is closing, even though the call itself succeeded. Anything reading that status is misled: on our staging proxy 97.9% of proxy spans were recorded as errors, against roughly 3% real failures in the gRPC metrics.

The change

Keep reading doneChan after the client half-closes, and return once the stream set has drained. TargetStreamSet.Empty is new and reports whether any stream is still expected to report completion.

Nothing changes while the client is still sending. Streams are only ever added in Add and removed in Remove, and Remove is called from the doneChan handler alone, so an empty set means every goroutine has finished and Wait returns immediately.

Testing

proxy/proxy/rpcstatus_test.go asserts the status gRPC reports for the proxy RPC, which is the value tracing exporters turn into a span status. It covers a single target, several targets, and a server-streaming method. All three fail on the current code with Unavailable: transport is closing and pass with this change.

go test ./proxy/... -race -count=2 passes. One unrelated pre-existing failure in ./server (TestServerWithUnixCredentials, supplementary group subtests) also fails on an unmodified checkout on macOS.

Deployed on our staging proxy, this moved proxy RPCs recorded as failed from 97.9% to zero over several thousand calls.