Add OAuth2 support

[hoeg]

This PR contains the addition of the login command to hamctl which will initiate an oauth2 device authorization flow.

The access token is persisted to disk and when it is expired the user must do a login again.

The release daemon and artifact executables has been moved to client credentials flow to have oauth2 on all the calls.

We support both the old auth token that is shared as well as the new jwt. The server must be configured with an IdP but this version is kept backwards compatible such that old clients can still use the server. When users have updated their cli's then we can remove the support for the static token.

The changes include that:

• We require oauth2 configuration to be set in the environment.
• The access token is persisted to disk in the $HOME/.Config directory (should be ok on all OS, right?)
• We bumped the golang version to v 1.20 to have access to the golang.org/x/oauth2 package
• Support both the old Authorization token and the new jwt in the server. The Actor is taken from the context, in case of the jwt supplied for auth or from the request if the old static access token is used.

Question for the reviewers:

Should we initiate a login if the token is invalid or should we just fail and tell the user to do a login instead?

Doing automatic logins will hopefully make for at better user experience but that might break e.g. scripts that cannot pop a browser.
@AndersSoee suggested that we could add an additional flag that indicates that we should not auto-login if the token is invalid.

Currently we just fail if the token is invalid and tell the user to log in.

We have been holding back on documentation as we would like to agree to the changes before writing it 🚀

[mahlunar]

Awesome.

I have som clarifying questions.

For us to release this gradually, then we should allow both authentication strategies. We could control this via a flag to avoid coupling a release here with out own deployment.

A release would follow these steps:

1. Deploy release manger with support for IDP
2. Move beta tests to use the IDP while the rest uses the old authentication flow
3. Move all developers to IDP flow via new hamctl version
4. Remove support for old authentication flow.

Can should be able to do the above steps after this PR is merged.

[hoeg]

Awesome.

I have som clarifying questions.

For us to release this gradually, then we should allow both authentication strategies. We could control this via a flag to avoid coupling a release here with out own deployment.

A release would follow these steps:

1. Deploy release manger with support for IDP
2. Move beta tests to use the IDP while the rest uses the old authentication flow
3. Move all developers to IDP flow via new hamctl version
4. Remove support for old authentication flow.

Can should be able to do the above steps after this PR is merged.

That is exactly how we also think the release procedure should be. We do allow both mechanisms so it is doable. I will address the other comments and resolve when they are done.

Next step is to figure out the IDP configuration, we do have a test setup that we have used to verify this implementation, but we should have something production ready set up.

I will let you know when we have resolved all comments 🚀

[hoeg]

I have nothing more to add. Would you mind giving it another look? 🙏