Fix spec failures due to PG::LockNotAvailable errors
We were seeing a high number of transient failures in the migration jobs
because with_lock_retries leaked non-zero, short lock_timeout values
(e.g. 100 ms) when used inside a Rails change method. If the
PostgreSQL autovacuum process happened to be running, it would lock the
table that it was vacuuming. During the migration rollback, if the DDL
operation needed a lock on the table, the short lock_timeout would
encounter the existing table lock and fail.
Even though SET LOCAL was used to ensure lock_timeout didn't leak
outside of the current transaction, the parent transaction would still
retain that value.
To avoid this issue, we should define separate up and down methods
so that we don't rely on the Rails magic to reverse a migration. This
ensures lock retries are used properly in both directions and prevents
lock_timeout from leaking during a migration rollback.
Closes #207088 (closed)