grpc: symbols: spread LocalCodeIntel response symbols across multiple messages

[ggilmore]

This PR changes the LocalCodeIntel symbols gRPC method to return a stream of chunks of symbols, rather than the entire result set in a single message.

---

gRPC has default limits on how large individual messages can be. This is because gRPC is a message-based framework, which means that messages have to be entirely loaded into memory for both sending and receiving. As such, large allocations can negatively impact server performance and stability. The go-grpc default limit is 4MB.

The original LocalCodeIntel RPC implementation (both gRPC and REST) returned the entire set of returned symbols in one message. For certain repositories / files, this message can contains thousands of symbols, which can add up to hundreds of MB or even gigabytes of memory.

This PR adjusts the server-side implementation of LocalCodeIntel to chunk up its full result set into smaller chunks (so that each individual gRPC message is smaller). It does this in a few steps.

• Adopting a chunk utility I found in the Gitaly project that can intelligently send a group of protobuf messages in smaller chunks (all ~ 1MB): https://github.com/sourcegraph/sourcegraph/pull/55242/commits/59ba6d0aba0c98a82d46b7a2f24127bbf97181cc
  • I made some minor tweaks to the original code here:
    • using generics for type-safety
    • supporting variadic arguments for convenience / ergonomics
    • removing some unneeded gitaly packages from the test setup
• Using the above chunk utility in the Symbols service to divide up the list of returned symbols into ~ 1MB batches and sending it across the result stream: https://github.com/sourcegraph/sourcegraph/pull/55242/commits/77fc77ee88e638c31c3ba8cba2b9f50f225503c5

---

Note that this PR doesn't "fix" the real issues with the underlying application itself. Notably:

• The server is still calculating the entire result set in one shot (requiring it to hold all the symbols in a contiguous chunk of memory), as opposed to sending out incremental progress.
• Is it necessary for the server to return thousands upon thousands of symbols, or should it support some sort of "limit" parameter?
• The custom symbols client API still returns all these symbols in one giant slice (by joining all the received messages), so it still allocates a lot of memory - same as before as opposed to some sort of API where the result can be consumed incrementally.

However, we still aren't any worse off than we were before (the REST implementation still has the same memory allocation problems and sends the results in one giant JSON message). This PR does "work around" the gRPC-specific message size complaints while providing a building block to improve this in the future.

cc @sourcegraph/code-intel ^

Test plan

1. CI
2. Manual testing:

• Using the repository and file mentioned in this log message, run a local sourcegraph instance with the following diff applied (to simulate the absence of the chunker by setting the message size to 1 TB)

diff --git a/internal/grpc/chunk/chunker.go b/internal/grpc/chunk/chunker.go
index 947b721368..c954854fc6 100644
--- a/internal/grpc/chunk/chunker.go
+++ b/internal/grpc/chunk/chunker.go
@@ -42,7 +42,7 @@ type Chunker[T Message] struct {
}

// maxMessageSize is the maximum size per protobuf message
-const maxMessageSize = 1 * 1024 * 1024
+const maxMessageSize = 1 * 1024 * 1024 * 1024 * 1024

• Nagivate to the above-mentioned repository and file, and hover over any token - see the expected log message:

 [       frontend] ERROR symbolsConnectionCache.gRPC.internal.error.reporter.streamingMethod.postMessageReceive internalerrs/logging.go:239 grpc: received message larger than max (708588568 vs. 94371840) {"grpcService": "symbols.v1.SymbolsService", "grpcMethod": "LocalCodeIntel", "grpcCode": "ResourceExhausted", "initialRequestJSON": "[omitted]"}

• Revert the above diff (which should restore the 1MB chunking behavior), and hard-refresh the blob page and hover over the same token. Eventually (after 30s) on my machine, the request will complete and a hover will appear - no error occurs.

[sourcegraph-bot]

Codenotify: Notifying subscribers in CODENOTIFY files for diff af19739...6aafcca.

Notify	File(s)
@keegancsmith	cmd/symbols/internal/api/BUILD.bazel cmd/symbols/internal/api/handler_cgo.go cmd/symbols/internal/api/handler_nocgo.go internal/symbols/client.go internal/symbols/client_test.go internal/symbols/v1/symbols.pb.go internal/symbols/v1/symbols.proto internal/symbols/v1/symbols_grpc.pb.go

[camdencheek]

Good stuff!

[camdencheek]

nit: seems like this will be the pattern used for pretty much every implementor of Sender. Should we just define something like the following?

type BufferedSender[T] {
    sendFunc: func([]T) error,
    buf []T
}

[camdencheek]

or maybe even just merge the buffer into the Chunker?

[ggilmore]

I can see the merit of the BufferedSender. Do you think we should get rid of the Sender interface entirely and replace it with BufferedSender, or just provide BufferedSender as a "default" implementation?

[camdencheek]

I can't actually think of a reason we'd need the Sender interface. The slice buffer + callback func seems general enough for any situation I can come up with

[ggilmore]

@camdencheek How does 334eba7 (#55242) look?

[camdencheek]

LGTM! Thanks!