Toolbox API comes with a basic oauth2 client. This commitsets-up details about two important oauth flows:- authorization flow, in which the user is sent to web page  where an authorization code is generated which is exchanged  for an access token.- details about token refresh endpoint where users can obtain  a new access token and a new refresh token.A couple of important aspects:- the client app id is resolved in upstream- as well as the actual endpoints for authorization and token refresh- S256 is the only code challenge supported

…ation urlOAuth endpoint `.well-known/oauth-authorization-server` provides metadata aboutthe endpoint for dynamic client registration and supported response types.This commit adds support for deserializing these values.

OAuth allows programatic client registration for apps like Coder Toolboxvia the DCR endpoint which requires a name for the client app, the requestedscopes, redirect URI, etc... DCR replies back with a similar structure butin addition it returs two very important properties: client_id - a uniqueclient identifier string and also a client_secret - a secret string valueused by clients to authenticate to the token endpoint.

Code Toolbox plugin should protect against authorization code interceptionattacks by making use of the PKCE security extension which involvesa cryptographically random string (128 characters) known as code verifierand a code challenge - derived from code verifier using the S256 challenge method.

…tion

The OAuth2-compatible authentication manager provided by Toolbox

- authentication and token endpoints are now passed via the login configuration object- similar for client_id and client_secret- PCKE is now enabled

…injection- remove ServiceLocator dependency from CoderToolboxContext- move OAuth manager creation to CoderToolboxExtension for cleaner separation- Refactor CoderOAuthManager to use configuration-based approach instead of constructor injectionThe idea behind these changes is that createRefreshConfig API does not receive a configurationobject that can provide the client id and secret and even the refresh url. So initiallywe worked around the issue by passing the necessary data via the constructor. However this approachmeans a couple of things:- the actual auth manager can be created only at a very late stage, when a URL is provided by users- can't easily pass arround the auth manager without coupling the components- have to recreate a new auth manager instance if the user logs out and logs in to a different URL- service locator needs to be passed around because this is the actual factory of oauth managers in ToolboxInstead, we went with a differet approach, COderOAuthManager will derive and store the refresh configs oncethe authorization config is received. If the user logs out and logs in to a different URL the refresh data isalso guaranteed to be updated. And on top of that - this approach allows us to get rid of all of the issuesmentioned above.

Toolbox can handle automatically the exchange of an authorization code with a tokenby handling the custom URI for oauth. This commit calls the necessary APIin the Coder Toolbox URI handling.

POST /api/v2/oauth2-provider/apps is actually for manual adminregistration for admin created apps. Programmatic Dynamic ClientRegistration is done via `POST /oauth2/register`.At the same time I included `registration_access_token` and `registration_client_uri`to use it later in order to refresh the client secret without re-registering the client app.

A bunch of code thrown around to launch the OAuth flow.Still needs a couple of things:- persist the client id and registration uri and token- re-use client id instead of re-register every time- properly handle scenarios where OAuth is not available- the OAuth right now can be enabled if we log out and thenhit next in the deployment screen