DM-42384: Add support for database migrations with Alembic

[rra]

Add a new oidc token type as an initial migration, which is not yet used but will be used in a subsequent change.

Use an async engine for Alembic, since that avoids needing to also install psycopg2 alongside asyncpg only for Alembic to use it. Since Alembic only sort-of supports async via asyncio.run, this requires moving the body of gafaelfawr init into a separate coroutine and running that with asyncio.run so that Alembic can be run outside of the running async loop.

The Alembic environment is a bit complicated at the moment and duplicates a bit of Safir code. A lot of this can be lifted into Safir in the future.

Fix a few problems with secret loading uncovered by loading the example configuration: the example OIDC client secrets were missing the new return_uri field, and newlines weren't removed from the end of secrets.

[rra]

This is the first time that I've used Alembic, and there were some non-obvious aspects to how to generate migrations and how to use an async database engine, so this seemed worth a code review.

[jonathansick]

This looks great. I think it overall matches up with my experience using Alembic with LTD Keeper.

Big picture, I do wonder about running alembic on app startup, especially in Kubernetes. In LTD Keeper I always ran the migrations from a specific Kubernetes Job before deploying the new codebase. My thinking was coloured by this article: https://pythonspeed.com/articles/schema-migrations-server-startup/

In practice it might be totally fine always running alembic, but I wanted to bring this up.

[rra]

Yeah, this was bothering me too and is a really good point. One of the things that's sort of entangled with this is that currently we run gafaelfawr init during startup, which creates the schema and would create any new tables, although it's somewhat safer since it doesn't modify any tables that already exist.

I feel like the right way to do this is to probably add a Helm chart parameter that says whether to automatically run schema updates (similar to the one for JupyterHub) and, if it is enabled, do a schema upgrade (and gafaelfawr init) as part of a Helm pre-install and pre-upgrade hook in a separate Kubernetes Job like you do with LTD Keeper.

I'll add this to my to-do list and in the meantime I'll drop the automatic Alembic run, and will do this update manually if I don't get around to the more complicated thing before I am ready to push out this release.

[rra]

Oh, and that uncovered another bug: I was running gafaelfawr init first, but that's wrong, since that will stamp the database with the latest Alembic version. Okay, I think I will have to implement the Helm hook thing for both gafaelfawr init and for Alembic to make this safe. I'll drop both from the startup script now so that I remember to do that.