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 set the lock_timeout back to the original value after we're done.

Note that developers using with_lock_retries should implement separate up and down methods if they want the lock retry mechanism to work in both directions.

Closes #207088 (closed)