Commit 392423a created a spec which would fail if a migration
in the current source tree was at an earlier timestamp than one
that has already been released, leaving us open to an issue where
we could run migrations out of order potentially causing schema
inconsistencies across regions.

The previous method relied on a file to determine which migrations
had been released. When that file was not updated when new
migrations were backported we left ourselves open to a false positive.

This change pulls the migrations from the github api right before
running the spec, ensuring that we have the latest data on backported
migrations.

In 7656212 a migration added "id" primary keys to some
tables that were being replicated. The triggers used in
rubyrep replication hardcode the "key" used to retrieve
the row that has been changed. In tables without a proper PK
these triggers were using multiple columns for this key.

Before this change, a migrated environment would have the same (old)
triggers firing on tables that now had a primary key which would
write the old key into the pending changes table. This mismatch
between what was recorded in the pending changes table and the
actual primary key caused an infinate loop / timeout during
rubyrep replication.

This fixes the situation by removing the triggers and other
replication state information for these tables and allowing
them to be rebuilt when replication starts again.

The new triggers will have the new primary key in them and
will generate changes that can be properly processed.

https://bugzilla.redhat.com/show_bug.cgi?id=1344456