background

Our REST P4Exec implementation first checks to see if the provided credentials are valid before running streaming the p4 output. If it's invalid, the server returns a http.BadRequest response to the client:

https://github.com/sourcegraph/sourcegraph/blob/3e50ff1a904b8fb0e6d2eb010e33cab56503c91d/cmd/gitserver/server/server.go#L1731-L1739

Our client implementation is written in such a way where these errors are immediately returned to the caller, without the need to consume the response body:

https://github.com/sourcegraph/sourcegraph/blob/457dc4813fc7614d84f91d0fb40404068ff1e362/internal/gitserver/client.go#L944-L956

old gRPC behavior

The gRPC version of this function does the same credentials check, but it didn't maintain the invariant of immediately
returning credential errors to the caller. Instead, the caller is required to start consuming the streamed response in order to see the error:

https://github.com/sourcegraph/sourcegraph/blob/3e50ff1a904b8fb0e6d2eb010e33cab56503c91d/internal/gitserver/client.go#L890-L912

This broke a call-site that only checked the immediate error returned by the client, and didn't actually consume the reader:

https://github.com/sourcegraph/sourcegraph/blob/dc0dfd1178326797e8c72f66af0c258960c3178c/internal/batches/sources/perforce.go#L82-L95

new gRPC behavior

This PR adjust the gRPC client to cache the first message it receives from the stream. If the first message is a permissions / credentials related error - it returns immediately before returning the stream. Otherwise, it returns the stream and yields all the same messages as it did before.

Test plan

Unit tests

Backport f7a1545 from #56298