Closes #44446.

The concurrency issue originates from inserts on
`user_interacted_projects` from the app while running the post-deploy
migration.

This change comes with a strategy to lock the table while removing
duplicates and creating the unique index (and similar for FK
constraints).

Also, we'll have a non-unique index until the post-deploy migration is
finished to speed up queries during that time.

Closes #44205.

We still have >100K unmigrated MergeRequestDiffs
which don't have commits_count set yet (see
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17567#note_61904891)

This migration re-schedules the original background migration.
To assure that records are not processed twice, records with
commits_count set are skipped.

Related to #41698 and !17567

See https://gitlab.com/gitlab-com/infrastructure/issues/3822

This reverts commit 0b7d1085.

This was causing user deletions to time out.

Closes #44008

API requests were timing out because `tag_id` was missing an index. These
migrations were imported by running https://github.com/mbleigh/acts-as-taggable-on#post-installation:

```
bundle exec rake acts_as_taggable_on_engine:install:migrations
```

It looks like the `acts-as-tagglable` gem added the indexes in v4.0.0, but
when we upgraded from v3.5.0 (back in 2016 via
f571aeb5) we did not add them.

On staging, there are about 10.7 million rows on the `taggings` table. It took about 30 seconds for each index to be created.

On production, there are about 17.4 million rows, so I suspect the time to be about a minute per index.

Closes #43927

Closes #43802

This flag will allow maintainers of a project to push to specific
branches of a fork of a project

This had the same name in EE, so give it a different name in CE.

Integrate two workers into one ArchiveTraceWorker with pipeline_background queue. This queue takes loqer precedence than pipeline_default.

This is to avoid a mix-up with the existing concept of 'user
contributions'. See `User#contributed_projects` or
`Event#contributions`.

MySQL does not return the number of inserted rows (or at least not
expose them through cmd_tuples). Let's do one-shot INSERT instead.

Trying to be a good citizen here, we spread the load building that
table. Maybe not required, but at least good practice and no harm.

* processes any pending records which are not migrated yet
* bumps import_export version because of new commits_count attribute
* removes commits_count fallback method

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>