https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21679 moved the
deletion of registry tags outside of a transaction, but introduced an
issue where Sidekiq would attempt to contact the container registry
during project destruction even if it were disabled.

Relates to:

* https://gitlab.com/charts/gitlab/issues/1455
* https://gitlab.com/gitlab-org/gitlab-ce/issues/45941

We should just ignore these errors and move along with the deletion
since the repositories are going to be trashed anyway.

Closes https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31164

Suggests to use a JSON structured log instead

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102

- Externalize strings in milestones_helper
- Externalize strings in app/services
- Update PO file

1. When removing projects, we can end-up leaving the +deleted
repo path dirty and not successfully removing the non-deleted
namespace (mv process is not atomic and can be killed without
fully moving the path).

2. In order to solve that, we're adding a clean-up phase on
ensure which will schedule possible staled +deleted path deletion.
Note that we don't check the current state (if there is or not a
repo) in order to schedule the deletion. That's intentional
in order to leverage Gitlab::GitalyClient::NamespaceService#remove
idempotency and ensure consistency.

This action doesn't lean on reduplication, so a short call can me made
to the Gitaly server to have the object pool remove its remote to the
project pending deletion.
https://gitlab.com/gitlab-org/gitaly/blob/f6cd55357/internal/git/objectpool/link.go#L58

When an object pool doesn't have members, this would invalidate the need
for a pool. So when a project leaves the pool, the pool will be
destroyed on the background.

Fixes: https://gitlab.com/gitlab-org/gitaly/issues/1415

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

Partially addresses #47424.

This adds a simple log message but also allows EE to insert database
events within the transaction (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6059/diffs).

When deleting associated records, Rails loads all associations into memory
(https://github.com/rails/rails/issues/22510) before destroying them. This
can cause a surge in memory and cause destruction of objects to fail
due to idle in transaction database timeouts. This fix is inspired from
https://github.com/thisismydesign to destroy `has_many` relationships
in batches.

Closes #44610

This is especially helpful when hashed storage is enabled

Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.

Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.

Closes https://gitlab.com/gitlab-org/gitaly/issues/1111

Closes #37462.

Partial fix to #44378

So we can keep showing it to a user in his project page.

The number of forks of a project doesn't change very frequently and
running a COUNT(*) every time this information is requested can be quite
expensive. We also end up running such a COUNT(*) query at least twice
on the homepage of a project.

By caching this data and refreshing it when necessary we can reduce
project homepage loading times by around 60 milliseconds (based on the
timings of https://gitlab.com/gitlab-org/gitlab-ce).

1. Rescue all errors that `Projects::DestroyService` might throw, to prevent the
   worker from leaving things in an inconsistent state

2. Unmark the project as `pending_delete`

3. Add a `delete_error` text column to `projects`, and save the error message in
   there, to be shown to the project masters/owners.