grpc: add prometheus server and client prometheus metrics

[ggilmore]

This PR does a few things (each commit is independently reviewable)

• rename webserver proto package from "grpc.v1" to "zoekt.webserver.v1" - this is for consistency
  • Renaming / moving the package made me realize that buf lint never` worked properly on this package. I also went ahead and fixed all the lint complaints.
• adds Prometheus gRPC server and client interceptors from https://github.com/grpc-ecosystem/go-grpc-middleware/tree/main/providers/prometheus, which implements standardized timing and error rates for the zoekt-webserver service and zoekt-sourcegraph-indexserver client

See https://github.com/sourcegraph/sourcegraph/pull/56525 for a screenshot of what the new zoekt-webserver gRPC dashboards look like in sourcegraph.

[keegancsmith]

github.com/sourcegraph/zoekt/cmd/zoekt-webserver/grpc/protos/zoekt/webserver/v1

why not one of the following

• github.com/sourcegraph/zoekt/proto
• github.com/sourcegraph/zoekt/web/proto

Nesting under cmd is a bit strange, especially for others to import. Makes somewhat sense in our monorepo, but not really for most projects.

More context: These are generating very deeply nested package names. Is that some sort of convention we are following? In the past I have just seen something simple like a proto pkg. Personally for a small project like zoekt keeping it simple feels good to me. But if this is a convention we are wanting to follow then ignore me.

[ggilmore]

github.com/sourcegraph/zoekt/cmd/zoekt-webserver/grpc/protos/zoekt/webserver/v1

why not one of the following

* github.com/sourcegraph/zoekt/proto

* github.com/sourcegraph/zoekt/web/proto

Nesting under cmd is a bit strange, especially for others to import. Makes somewhat sense in our monorepo, but not really for most projects.

More context: These are generating very deeply nested package names. Is that some sort of convention we are following? In the past I have just seen something simple like a proto pkg. Personally for a small project like zoekt keeping it simple feels good to me. But if this is a convention we are wanting to follow then ignore me.

Two things:

First: the package name services as a unique identifer for the service in question:

zoekt/grpc/protos/zoekt/webserver/v1/webserver_grpc.pb.go

Line 22 in 736c674

WebserverService_Search_FullMethodName = "/zoekt.webserver.v1.WebserverService/Search"

zoekt.webserver.v1.WebserverService is the full name of the service. The service name is how you target this particular service when using other gRPC tools (like our Grafana dashboards, clients, etc.). So, it was important to make sure that it is globally unique and identifiable.

Second: In GRPC, the folder structure also must mirror the package name. zoekt.webserver.v1 implies that there is a zoekt/webserver/v1 folder hierarchy. (we can't use the root of the repository git checkout as the initial folder since you can change the name to be whatever you want, so we need to explicitly create this nested folder hierarchy)

The protobuf file resolution process (that compilers, Wireshark, etc. all use) depends on this folder hierarchy being correct.

So between those two points, we need the zoekt/webserver/v1 folders somewhere in the repository. However, I did move it from cmd/zoekt-webserver to grpc/protos after your comment.