Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

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

Opitmize migration process by using both unmanaged_kubernetes_service and kubernetes_service_without_template

If a later spec tries to set a field that is added to any of these models by a
later migration than the GCP clusters migration, it will fail because the
model's columns are cached.

We should always refer to models in migration specs by either their class in the
migration, or the table directly, using the `table` helper.

This adds a minimum interval to BackgroundMigrationWorker, ensuring
background migrations of the same class only run once every 5 minutes.
This prevents a thundering herd problem where scheduled migrations all
run at once due to their delays having been expired (e.g. as the result
of a queue being paused for a long time).

If a job was recently executed it's rescheduled with a delay that equals
the remaining time of the job's lease. This means that if the lease
expires in two minutes we only need to wait two minutes, instead of
five.

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

Both the post-deploy and background migration.

According to https://dev.mysql.com/doc/refman/5.7/en/update.html,
"You cannot update a table and select from the same table in a subquery."
Attempting to do so results in the error:

```
Mysql2::Error: Table 'issues' is specified twice, both as a target for 'UPDATE' and as a separate source for data
```

Instead, we can use a LEFT JOIN on the same table to make MySQL do the right
thing.

Closes #41498

Instead of using the factories. Since the factories might be using
columns that aren't available in the schema at version the particular
spec is running in.

This migration also needs to be a post-deployment migration, as it removes a
column.

Later migrations added fields to the EE DB which were used by factories which were used in these specs.

And in CE on MySQL, a single appearance row is enforced.

The migration and migration specs should not depend on the codebase staying the same.

* 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.

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.