When a container registry has many tags, it's easy for the DELETE call to take more
than 60 seconds and fail. This can also leave the registry in a bad state with
null bytes since some of the images have been deleted with tags still pointing to them.
In addition, we have to prevent users from accidentally initiating the delete multiple
times or this could leave the registry with orphaned tags.

This commit also adds a flash message to notify the user the registry is scheduled
for deletion.

Closes #49926, #51063

The feature has been running on GitLab.com for a while now, without any
problems. This commit removes the eature flag, and enables the feature
for all users.

This whitelists all existing places where we use "destroy_all".

The repository languages feature got introduced through:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19480. This MR
included feature flags to guard against performance regressions, which
allowed GitLab to test it on gitlab.com before the customers would be
exposed.

.com worked out fine, as shown by our internal monitoring tools, which
prompts feature gate removal.

Given the docs weren't present yet, these were added too.

Partially addresses #47424.

This changes the BackgroundMigration worker so it checks for the health
of the DB before performing a background migration. This in turn allows
us to reduce the minimum interval, without having to worry about blowing
things up if we schedule too many migrations.

In this setup, the BackgroundMigration worker will reschedule jobs as
long as the database is considered to be in an unhealthy state. Once the
database has recovered, the migration can be performed.

To determine if the database is in a healthy state, we look at the
replication lag of any replication slots defined on the primary. If the
lag is deemed to great (100 MB by default) for too many slots, the
migration is rescheduled for a later point in time.

The health checking code is hidden behind a feature flag, allowing us to
disable it if necessary.

Resolve "Hashed storage: extend "Enable hashed storage for all new projects" to "for all new and renamed projects""

Older versions of GitPushService push a single commit SHA string to the queue,
but Gitaly requires that the parameters sent by CreateGpgSignatureWorker are
an array. It's possible to have old workers using this original signature or
jobs in the retry queue that would fail if CreateGpgSignatureWorker can't
handle the string form.

Our friends at GitHub show the programming languages for a long time,
and inspired by that this commit means to create about the same
functionality.

Language detection is done through Linguist, as before, where the
difference is that we cache the result in the database. Also, Gitaly can
incrementaly scan a repository. This is done through a shell out, which
creates overhead of about 3s each run. For now this won't be improved.

Scans are triggered by pushed to the default branch, usually `master`.
However, one exception to this rule the charts page. If we're requesting
this expensive data anyway, we just cache it in the database.

Edge cases where there is no repository, or its empty are caught in the
Repository model. This makes use of Redis caching, which is probably
already loaded.

The added model is called RepositoryLanguage, which will make it harder
if/when GitLab supports multiple repositories per project. However, for
now I think this shouldn't be a concern. Also, Language could be
confused with the i18n languages and felt like the current name was
suiteable too.

Design of the Project#Show page is done with help from @dimitrieh. This
change is not visible to the end user unless detections are done.

Enables frozen string for new files in
directories that had been previously
covered in previous MR's.

Partially addresses #47424.

If you enter the following RFC 2822 compliant address:
`John Doe <john@doe.com>`

Gitlab will attempt to send three emails:
1) John
2) Doe
3) john@doe.com

With this change given the following:
`John Doe <johndoe@example.com>`
`Jane Doe <janedoe@example.com>`

Gitlab will send emails to `johndoe@example.com` and `janedoe@example.com`

When the Gitaly call failed, the exception handling failed
because `method` is expected to have a parameter.

Closes #49096

We saw in production that DispatchWorker was running about twice an hour,
which would schedule twice as many jobs as it should.

For some reason, BatchWorker was running 1000 times per hour, possibly
due to Sidekiq RSS kills that caused these jobs to restart.

Adding an ExclusiveLease prevents these jobs from running more
than they should.

Relates to https://gitlab.com/gitlab-com/infrastructure/issues/4526

This reverts merge request !20103

This adds a recurring Sidekiq job that removes up to 50 000 old web hook
logs per hour, if they are older than 90 days. This will prevent the
web_hook_logs table from growing indefinitely.

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

There is only 1 `HEALTHY_SHARD_CHECKS` used:
Gitlab::HealthChecks::GitalyCheck

So we can simplify code to get the list of healthy shard names.

The RepositoryCheck::DispatchWorker will start a
RepositoryCheck::BatchWorker for each healthy shard.

Closes gitlab-org/gitlab-ce#48042

It already existed in EE in the Geo namespace. This change brings it
to CE.