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

Prior to this change, a feature flag could be used to disable this
feature. Now all requests go through Gitaly's OperationService.

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

When vendoring `Gitlab::Git` again in Gitaly, this implemenation will be
gone, but this is readded there through:
https://gitlab.com/gitlab-org/gitaly/merge_requests/717

Has been in opt out for 5 months, and within GitLab been in production
for longer than that.

No code needs to be migrated as this is implemented in GoLang over at
Gitaly.

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

We saw that in a customer instance, `empty?` was cached to be `true` even
though `has_visible_content?` and `exists?` were `true`. This double caching
can run into edge cases because there's no guarantee that the inner values
will properly expire the outer one, especially if there is Redis replication lag.
Consider this scenario:

1. `exists?` and `has_visible_content?` are false
2. `empty?` is expired
3. A subsequent call to `empty?` returns `true` because `exists?` is false even though `empty` is true
4. `exists?` and `has_visible_content?` are then expired
5. `exists?` and `has_visible_content?` are set to true
6. `empty?` is still stuck in the wrong value as `true`

Closes #43882

We removed the exception handling for Rugged errors in !16770, which
revealed that the licensee gem attempts to retrieve a license file
via Rugged in `refs/heads/master` by default. If that branch
did not exist, a Rugged::ReferenceError would be thrown.

There were two issues:

1. Not every project uses `master` as the default branch. This
change uses the head commit to identify the license.

2. Removing the exception handling caused repositories to fail
loading. We can safely catch and ignore any Rugged error because
this means we weren't able to load a license file.

Closes #43268

Gitlab::Git::Repository#find_branch has a similar logic.

Fixes #42609

As part of gitlab-org/gitaly#884, this commit contains the client
implementation for both TagNamesContaintingCommit and
BranchNamesContainingCommit. The interface in the Repository model stays
the same, but the implementation on the serverside, e.g. Gitaly, uses
`for-each-ref`, as opposed to `branch` or `tag` which both aren't
plumbing command. The result stays the same.

On the serverside, we have the opportunity to limit the number of names
to return. However, this is not supported on the front end yet. My
proposal to use this ability: gitlab-org/gitlab-ce#42581. For now, this
ability is not used as that would change more behaviours on a feature
flag which might lead to unexpected changes on page refresh for example.

A file containing /:\d+:/ in its contents would break the search results if
those contents were part of the results, because we were splitting on colons,
which can't work with untrusted input.

Changing to use the null byte as a separator is much safer.

Closes #41739

This reverts merge request !15712

Uses `list_commits_by_oid` on the CommitService, to request the needed
commits for pipelines. These commits are needed to display the user that
created the commit and the commit title.

This includes fixes for tests failing that depended on the commit
being `nil`. However, now these are batch loaded, this doesn't happen
anymore and the commits are an instance of BatchLoader.

Allows ordering in GET api/v4/projects/:project_id/repository/contributors
through `order_by` and `sort` params.
The available `order_by` options are: name|email|commits.
The available `sort` options are: asc|desc.