Initial bearer token expiry is a problem for declarative systems

After a discussion with DanielMesser about https://access.redhat.com/solutions/5462311 ...
 
The Validated Patterns mission is to automate real-world customer use cases using a GitOps-style declarative approach.  This naturally precludes the use of the Quay UI.
 
As part of the initial automation, we generate and use the initial OAuth bearer token using the /api/v1/user/initialize endpoint (see cm-create-quaye-pull-secret.yaml) which works fine for setup.
 
However since this is a declarative system, the admin may make changes after the initial token expires (150min).

Our problem is that most API calls cannot make use of Basic authentication, and there is no way to obtain a new OAuth token without either using the UI or making invasive changes to Quay.

The approach described in the kcs above requires either knowing the client ID in advance (impossible) so that quay can be provisioned correctly in the first place, or doing a slow and complex/fragile dance of:

1. initializing quay enough to create the application,
2. reconfiguring quay to whitelist the resulting client ID,
3. finding and killing the relevant pods,
4. waiting for them to come up again
5. using the /oauth/authorize endpoint to obtain a new token
6. completing the configuration

We would like the ability to have either:

• an initial bearer token that does not expire, or
• the ability to create new ones without fundamentally reconfiguring and tearing down quay