Better support for downgrading Aerie & running down-migrations

[dandelany]

Background

The Aerie DB migration script supports running down (ie. backward) migrations, for downgrading the database to older versions of Aerie - this is mostly used for troubleshooting, or if a customer encounters a blocker issue on a later version and wants to use an earlier version.

This process is somewhat documented in the docs here: https://nasa-ammos.github.io/aerie-docs/deployment/advanced-database-migrations/

Description

The docs for downgrading Aerie version could use improvement to make it clear what to do. It's a bit non-intuitive to run, and requires knowing which down migrations need to be run in advance. It would be great if the script could determine which migrations need to be run (maybe given a version number) - but failing that, the process for determining which ones to run should at least be documented

[Mythicaeda]

Two ideas to help track which migrations are needed to be on a specific Aerie DB version:

1. Add a column to the migrations table that includes the Aerie release version of the migration. This would require developers to include and update the release version in both the up.sql and the init.sql, especially if a PR "slips" a release. This approach would have the benefit of the data being always available in the DB.
2. Add a file to the deployment directory that tracks which migrations came out in the release. This has the advantage of being straightforward to update while cutting a new release. It has the disadvantage of requiring users to have and regularly pull the file.