And use :migration tag to use deletion strategy, and to avoid caching tables, and to lock into a particular schema.

Attempting to fix intermittent spec errors `PG::UndefinedTable: ERROR:  relation "public.untracked_files_for_uploads" does not exist`.

Since the migration might be queued already and be rescheduled when it
fails on a uniqueness error, this should help clearing the background
migration queue faster.

Prior to this commit we would essentially update all rows in a table,
even those where the source column (e.g. `issues.closed_at`) was NULL.
This in turn could lead to statement timeouts when using the default
batch size of 10 000 rows per job.

To work around this we don't schedule jobs for rows where the source
value is NULL. We also don't update rows where the source column is NULL
(as an extra precaution) or the target column already has a non-NULL
value. Using this approach it should be possible to update 10 000 rows
in the "issues" table in about 7.5 - 8 seconds.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/42158

with StrongMemoize

For each MR diff an extra 'SELECT COUNT()' is executed
to get number of commits for the diff. Overall time to get counts for
all MR diffs may be quite expensive. To speed up loading of MR info,
information about number of commits is stored in a MR diff's extra column.

Closes #38068

If the payload cannot be created for some reason, we could be left with a nil
push event payload, which causes Error 500s when viewing the dashboard. Guard
against this error and log when it happens.

Avoids problems seen in #38823

Both the post-deploy and background migration.

In a previous attempt (rolled back in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16021) we tried
to migrate `issues.closed_at` from timestamp to timestamptz using a
regular migration. This has a bad impact on GitLab.com and as such was
rolled back.

This commit re-implements the original migrations using generic
background migrations, allowing us to still migrate the data in a single
release but without a negative impact on availability.

To ensure the database schema is up to date the background migrations
are performed inline in development and test environments. We also make
sure to not migrate that that doesn't need migrating in the first place
or has already been migrated.

In particular, the Omnibus uploads directory is generally a symlink.

To fix for MySQL.

`updated_at` is now unnecessary and `created_at` is less useful due to removing the tracked field.

It makes a debugging slightly easier, but is not necessary, and is a waste of resources.

* Hopefully fixes spec failures in which the table doesn’t exist
* Decouples the background migration from the post-deploy migration, e.g. we could easily run it again even though the table is dropped when finished.

Since `calculate_checksum` depends on `Uploader` classes which are not defined in this background migration and may change at any time.

So the path on source installs cannot be too long for our column.

And fix the column length test since Route.path is limited to 255 chars, it doesn’t matter how many nested groups there are.