I don't like the idea of `RequestStore` at all, because it's just a
global state which shouldn't be used at all. But we have a number of
places calling `ProtectedBranch.protected?` and `ProtectedTag.protected?`
in a loop for the same user, project, and ref whenever we're checking
against if the jobs for a given pipeline is accessible for a given user.
This means we're effectively making N queries for the same thing over
and over.

To properly fix this, we need to change how we check the permission,
and that could be a huge work. To solve this quickly, adding a cache
layer for the given request would be quite simple to do.

We're already doing this in Commit#author, and this is extending that
idea and make it generalized.

Simply re-raise an exception when it occurs, but guarantee that no
background migration is lost in the process.

It also makes it possible to gracefully retry a migration in order to
avoid problems like deadlocks.

We first pop a job from the Sidekiq queue / scheduled set and only if
this has been successfully deleted we process the job. This makes it
possible to minimize a possibility of a race condition happening.

When sign-in is disabled:
 - skip password expiration checks
 - prevent password reset requests
 - don’t show Password tab in User Settings
 - don’t allow login with username/password for Git over HTTP requests
 - render 404 on requests to Profiles::PasswordsController

Otherwise some features would go untested in non-specific contexts

I did need to disable the
`gitlab_git_diff_size_limit_increase`-feature in some specs since we
depend on diffs being expandable while the file we are testing on is
smaller than the increased limit.

+ fix tests after metrics rename

Add `seconds` unit to latency metrics based on uptream naming
convention[0].

[0]: https://prometheus.io/docs/practices/naming/#metric-names

* Follow Prometheus naming conventions[0].
* Simplify metrics by adding response lables to the histogram.
* Use standard `http_request_duration_seconds_...` names for the histogram.

[0]: https://prometheus.io/docs/practices/naming/#metric-names

Closes gitaly#355

The implementation now simply rely on the
`performance_bar_allowed_group_id` Application Setting.
Signed-off-by: NRémy Coutable <remy@rymai.me>

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

This is an ID-less table with just three columns: an association to the merge
request diff the commit belongs to, the relative order of the commit within the
merge request diff, and the commit SHA itself.

Previously we stored much more information about the commits, so that we could
display them even when they were deleted from the repo. Since 8.0, we ensure
that those commits are kept around for as long as the target repo itself is, so
we don't need to duplicate that data in the database.

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

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

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

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