add support for dynamic application registration for notebooks

[Panaetius]

Keycloak does not currently support wildcards in URL callbacks, which is needed for #1322 .

They are working on support, (see keycloak/keycloak/issues/14380 and keycloak/keycloak/discussions/9278 ) but it's unclear when this might be done.

To support this, we need to have fully defined callback URIs in keycloak, like https://session_name.sessions.dev.renku.ch/oauth2/callback, and the easiest way to achieve that is to create dynamic keycloak clients, one per session.

This can be done as described here, namely:

• on session start, notebook-service creates a new dynamic client through the keycloak api (possibly with limited time to live), with the session-specific callback-URI
• keycloak sends back a clientId and client secret
• notebook-service patches the clientId/secret into the jupyterserver resource (or as a secret)
• amalthea patches those values into the oauth2-proxy here and here
• on session stop, we need to invalidate the client.

[olevski]

Perhaps having a centralized authentication/authorization service could help here. In this case the session ingress would point to this central service for its main ingress. The service can evaluate the token, decide whether a user should have access and proxy the request. This would also mean we would not need the oauth2 proxy in every session.

Because the main problem is that the callback to the oauth2 proxy in each session that now lives in a different subdomain. But if we rely on such a centralized service which would live under a predictable domain/path (and not one that changes for every session) then we would not have the invalid redirect url problem and we would not need to use a wildcard for the callback.

[olevski]

Additional thing to note here. We do not even need an authz service for this. We can simply authenticate the user (like we do now) but instead of using the oauth2proxy we would use the gateway or a similar centralized service.