[public-api] Refactor to use connect handlers, route to HTTP server

[easyCZ]

Description

In this PR, we 1-1 map the old implementation in gRPC to the new implementation with Connect. Changes are deliberately not made to streamline the tests and simplify to keep the PR cleaner.

In general, the changes are the following (see docs)

1. Use the generated ServiceHandlers
2. Wrap requests and responses in connect.NewRequest or connect.NewResponse
3. Use Connects error codes
4. Use HTTP server in tests

This PR also changes default routing of api.<domain> requests to the HTTP server, this has the following effect:

• Connect handlers handle both gRPC and HTTP traffic - this is fine, as Connect is designed for this
• Depending on the rollout sequencing, there can be a brief period where requests would fail. This is OK, as we don't get any traffic on this yet anyway.

Related Issue(s)

• Depends on [public-api] Authentication interceptors for connect API #13693

How to test

Unit tests

1. Log in to preview and run the following in the console to get an access token:

	await window._gp.gitpodService.server.generateNewGitpodToken({ type: 1, scopes: ["function:getGitpodTokenScopes",
	"function:getWorkspace",
	"function:getWorkspaces",
	"function:listenForWorkspaceInstanceUpdates",
	"resource:default",]})

To make subsequent steps readily runnable, export the token in your shell:

export BEARER_TOKEN="<token>"

Validate we can reach the new APIs over cURL:

curl \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer $BEARER_TOKEN" \
    --data '{}' \
    https://api.mp-public-72e473c7b0.preview.gitpod-dev.com/gitpod.v1.WorkspacesService/ListWorkspaces | jq

{}

We're doing a list call, and we don't have workspaces so an empty list response is expected.

Validate we can reach the APIs using a gRPC client

gpctl api workspaces list --address api.mp-public-72e473c7b0.preview.gitpod-dev.com:443 --token $BEARER_TOKEN 

ID        Owner        ContextURL

Again, we're not getting any workspaces back because we've not started any but the important part is we're not getting an error.

Release Notes

NONE

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide

[werft-gitpod-dev-com]

started the job as gitpod-build-mp-public-api-connect-refactor.1 because the annotations in the pull request description changed
(with .werft/ from main)

[jenting]

Changes for workspace team component LGTM

[geropl]

Starting to review now

[geropl]

Asking for posterity: Is there an alternative to riddling our implementation with references to connect? It's not a big concern, as the changes look rather mechanical (near search-and-replace). Still wondering if there is a way to have a ConnectProxy[T] that does the wrapping for us (I'm aware that this might be a tough ask for Go 🙃 ).

Additionally, would it maybe make sense to hide a bit of the connect-specific function (like connect.NewError) behind minimal wrappers? IMO those can help explain why you have to do it this way, and not use the regular gRPC errors 🤔

[easyCZ]

In general, we don't want to make this magic. We also want to stay as close to the official connect documentation as possible such that we don't need to re-teach things internally.

If it's just a wrapper, it's not adding match aside from importing the function from elsewhere (and that place imports connect).

[geropl]

We also want to stay as close to the official connect documentation as possible

IMO the ideal situation would be if we could stick to the gRPC documentation. But I can definitely live with this. 💯 It's not in the interest of connect, but maybe someone writes a wrapper at some point that we can use. 🙂

[easyCZ]

Yes, but if we stuck with gRPC documentation then you'd not know you can invoke it with curl and use JSON as the payload - in Go principles we should not hide things, and the difference (or complexity) should be visible directly

[geropl]

in Go principles

I know, I know... but abstraction is a powerful concept as well 😆 (if it does not leak too much, hence I'm fine with as-is).

[geropl]

When testing as described I get a bad handshake - 401 / authorization header does not have a Bearer prefix: missing access token (with both methods).

[easyCZ]

When testing as described I get a bad handshake - 401 / authorization header does not have a Bearer prefix: missing access token (with both methods).

Ah, sorry. You need to either re-install gpctl or use cd dev/gpctl && go run main.go api workspaces list --address api.mp-public-72e473c7b0.preview.gitpod-dev.com:443 --token $BEARER_TOKEN - that's because of the fix to gpctl in this PR

If you had opened the workspace from this branch, it would've worked as it would've been prebuilt.

The curl command was not interpolating the $BEARER_TOKEN variable due to single quotes, updated and should work now.

[geropl]

You need to either re-install gpctl

Ah thx, my bad. 🙈 gpctl works now 🧘

But I don't get why curl didn't work before but did now 😢

Update: Noticed you updated the description from --header 'Authorization: Bearer $BEARER_TOKEN' to --header "Authorization: Bearer $BEARER_TOKEN": That explains it. ✔️

If you had opened the workspace from this branch

I did, but gpctl is only updated on dev image builds (ref). 👍

[geropl]

Changes LGTM, tests run and manual test works - nice work! 🎉

[easyCZ]

I did, but gpctl is only updated on dev image builds (ref). 👍

Ah my bad, I should've made it more epxlicit.