- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level

**Prevention of running 2 simultaneous updates**

Instead of using `RemoteMirror#update_status` and raise an error if
it's already running to prevent the same mirror being updated at the
same time we now use `Gitlab::ExclusiveLease` for that.

When we fail to obtain a lease in 3 tries, 30 seconds apart, we bail
and reschedule. We'll reschedule faster for the protected branches.

If the mirror already ran since it was scheduled, the job will be
skipped.

**Error handling: Remote side**

When an update fails because of a `Gitlab::Git::CommandError`, we
won't track this error in sentry, this could be on the remote side:
for example when branches have diverged.

In this case, we'll try 3 times scheduled 1 or 5 minutes apart.

In between, the mirror is marked as "to_retry", the error would be
visible to the user when they visit the settings page.

After 3 tries we'll mark the mirror as failed and notify the user.

We won't track this error in sentry, as it's not likely we can help
it.

The next event that would trigger a new refresh.

**Error handling: our side**

If an unexpected error occurs, we mark the mirror as failed, but we'd
still retry the job based on the regular sidekiq retries with
backoff. Same as we used to

The error would be reported in sentry, since its likely we need to do
something about it.

Don't attempt to contact registry if it is disabled

See merge request gitlab-org/gitlab-ce!31553

- Closes #60024

- Change PrometheusClient.new to accept a base url instead of an
  already created RestClient

- Use Gitlab::HTTP in PrometheusClient instead of creating RestClient
  in PrometheusService

- Move http_options from PrometheusService to
  PrometheusClient (follow_redirects: false)

- ensure that base urls don't have the trailing slash

- Created a `PrometheusClient#url` method that might not be strictly
  required

- Change rescued exceptions from RestClient::* to
  HTTParty::ResponseError where possible and StandardError for the
  rest

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

This MR adds new application setting to network section
`allow_local_requests_from_system_hooks`. Prior to this change
system hooks were allowed to do local network requests by default
and we are adding an ability for admins to control it.

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

This means we have one less Net::HTTP monkeypatch.

sham_rack cannot handle IPv6 addresses which means it breaks Net::HTTP
connections because it monkey-patches Net::HTTP

These are not required because MySQL is not
supported anymore