In retrospect a primary key that has no relation to the certificate is preferred to using the certificate KeyID. The KeyID is also very large for a primary index.
This is a moderately tricky migration, especially for SQLite which has no means of altering the table in this fashion - it involves creating the new table and copying the data.
Order of commands also matters - index names are global in SQLite, so the `idx_expires_at` index needs to be created at the correct stages.

For MySQL migration the necessary steps are run as a single alter statement to minimise the risk of leaving the migration in an incomplete state if anything aborts.

When tested on a table with 250,000 rows (MySQL 5.7) the migration took 3 seconds to complete. As certificates will be requested infrequently the risk of prolonged locking is minimal.

It's currently hard to make changes to the database schema. Use sql-migrate to make incremental changes.
Stop hard-coding the database name (the default is still "certs" for backward-compatibility)
The `automigrate()` function will automatically run pending migrations.
Use a different migration directory per database driver. This carries a cost of duplication, but is easier than creating migrations which will cleanly execute in both SQLite and MySQL.
Migrations are shipped using the packr utility.