Replace gorm.AutoMigrate

[dnephin]

In #2584 we identified gorm.AutoMigrate is the most significant source of time when running tests against postgreSQL. By replacing AutoMigrate we can more easily run all of our tests against postgreSQL. Removing it will also give us a much clearer picture of the SQL that is being used to construct and modify our database tables.

However, there are two consequence to removing AutoMigrate:

1. we will need to write explicit migrations every time we add, or change a table or column
2. we will need to create and manage the initial schema used to populate a database

Units of work:

• convert our migration tests to a table driven test. See section below for more details Replace migration tests with a single table drive test #2770
• remove old migrations to limit the number we need to add data: remove migrations from pre-0.12.0 #2764
• replace migration implementations with regular SQL, especially the ones that use AutoMigrate Replace the last of AutoMigrate #2862
• replace the last remaining data/migrator use of gorm heleprs (db.Migrator().HasTable) Replace gorm.Migrator calls with sql #2846
• replace gorm.AutoMigrate with an initial schema generated from a database dump that we embed with go:embed Replace gorm.AutoMigrate with schema.sql #2843

Table driven tests

A table driven test has a few advantages:

1. it lets us easily compare the list of migrations to the list of test cases for migrations. This gives us the opportunity to prompt the contributor to add a test case when they are adding a migration. If the list of migrations contains an ID that isn't in the list of test cases we can fail the test and indicate they should add a test case.
2. we can run each migration from a database initialized by running all previous migrations. This removes the need to dump the schema for a database every time we write a migration test. We'll only need to dump a new schema when we remove old migrations.
3. we'll also be able to leverage this table test to either dump the fully migrated schema (which we'll embed using go:embed) for initializing new databases, or if we decide to keep the schema in the Go source, we can use the test to assert that the migrated schema is identical to the schema stored in the Go source.