Replace improbable-eng/grpc-web with grpc/web

[absoludity]

Summary Improbable stopped supporting grpc-web a while back since the official repo was launched.

We should update to the official grpc-web version. Unfortunately it's not that simple though, since the official grpc-web version has the client-side implementation, but does not have the server-side in-process grpc-Web -> grpc translation (at least for go), instead utilising envoy to do the translation.

We may need to investigate depending on envoy for the translation.

[absoludity]

So bufbuild's connect library is now at a 0.8.1 release, over 6 months after their initial announcement and has some features that would be very nice for us:

• they fully support the gRPC-Web protocol (and have an extended version of gRPC's own compatibility suite to ensure it remains that way)
• Switching your frontend (typescript) code between the gRPC-Web protocol and their own connect-web (now connect-es) protocol is a single line (different constructor - no change to the client usage), which gives you
• a go library - connect-go which does what improbable-web's go library gave us: translation from the web protocol to native gRPC, so no need for envoy or something in between

This would allow us to transition the code as follows:

1. Generate the typescript clients using buf and connect
2. Update our dashboard code to use the new clients but still with gRPC-Web protocol, which should continue to work with the existing improbable-eng backend translation
3. Switch the backend to use connect-go and update the dashboard client code (just changing the client constructor)

If we ever change our minds and want to use envoy + gRPC-Web, it's a single-line change to switch back, so no lock-in.

I'm investigating this as the way forward, looks much nicer to use as well, appears to be much more active, better documented and has the same Apache 2.0 license.

[absoludity]

I've been investigating switching the backend over and realised that our use of grpc-gateway, to provide a ReST-ish version of the API (in addition to the grpc and grpc-web), won't be possible, since it is supported by the generated code of the tied with the standard gRPC registration of services.

We don't use this outside of a liveness check (which we should replace with a grpc check anyway), but we have advertised it as an optional API (which could change at any time), and do currently use it to generate the openapi spec.

This has been discussed on the connect-go project: https://github.com/bufbuild/connect-go/discussions/256 . We could potentially continue to generate the openapi spec by updating the http annotations to match the connect http.

[absoludity]

I've been investigating switching the backend over and realised that our use of grpc-gateway, to provide a ReST-ish version of the API (in addition to the grpc and grpc-web), won't be possible, since it is supported by the generated code of the tied with the standard gRPC registration of services.

Actually, this isn't true. We are able to continue using the grpc-gateway.. we just need to forward the http requests to the new endpoint and it works fine. See #6150