[supervisor] Initial design and implementation of the token service

[csweichel]

This PR introduces a token service in supervisor.

(Note: the vast majority of additions in this PR is auto-generated protocol code or license header.)

Why do we need this?

In the past the Theia Gitpod extension, more specifically its frontend, acted as "proxy" towards the Gitpod API and relied on the user's session authentication to authenticate. Now that more and more functionality is moving towards supervisor and other clients (e.g. other IDEs), we need to ensure they, too can access the Gitpod API. Where #1868 introduces the "service side" of things, this PR introduces some infrastructure to make tokens practical in a workspace.

Idea

The idea is that we have a central service - supervisor - that acts as "doorman", collecting keys to various services (first and foremost, the Gitpod API, but also GitHub tokens). Supervisor clients - e.g. CLI or the supervisor frontend - can provide tokens upon request or prophylactically. They can also request tokens that were previously provided.

Ideally the supervisor frontend would, in the future, use its session auth to generate an API token that supports/enables the basic functioning of a workspace. It would be specifically scoped (function:heartbeat, function:getWorkspace, resource:workspace::<thisWorkspaceID>::get, etc.) and be made available to other consumers within the workspace by virtue of the supervisor token service.

When someone in the workspace needs e.g. a GitHub token, they can also ask supervisor who would forward the request to its providers, e.g. the supervisor frontend. The frontend can then decide if it wants to deny the request, ask the user or just provide a token. This is in analogy to how the Git authentication works today, only that it's supervisor instead of Theia talking to the Gitpod server.

Controlling token reuse

Token provider can determine how supervisor gets to reuse the token they've provided. There are three modes:

1. never whereby a token must be used just this once and can never be cached/provided to other consumers.
2. exactly whereby a token can be reused if the requested scopes match exactly those of the token; this is to prevent accidental privilege escalation.
3. when possible whereby a token can be reused whenever possible, e.g. if the list of requested scopes is a subset of those provided by the token. This is primarily an optimisation and intended for the workspace token described above. If, e.g. we need a token to "open a port", we can ask for one with function:openPort and would be given a token that, amongst others has function:openPort,resource:workspaceInstance::<thisWorkspaceInstanceID>::update.

Future work

1. Provide tokens from supervisor frontend: there are no clients of this new token API yet, neither consumer nor provider. A first step would be to provide Git auth tokens and Gitpod API tokens from the frontend.
2. Use the token API to provide Git auth tokens in the credential helper: gp acts as credential helper to Git. Right now it asks Theia for the token, but should ask supervisor instead.
3. Use the token API to auto-expose ports: currently it's Theia who auto-exposes ports privately. Instead it should be supervisor who does that when a served port opens. This end it would need to request a token to talk to the Gitpod API.

[akosyakov]

It does not seem to have any consequences for end users and code-wise looks good to me.