This reduces conflicts with EE, where it is public because it is
called in ee/lib/gitlab/ci/external/file/local.rb.

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

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

Fixes gitaly#1057

The old code was calling LastCommitForPath to extract a commit ID _then_
call FindCommit to get a commit it already had in the first place!

By default, --prune is added to the command-line of a `git fetch` operation,
but for repositories with many references this can take a long time to run. We
shouldn't need to run --prune the first time we fetch a new repository.

Closes gitaly#1054

Part of the migration as tracked in: gitlab-org/gitaly#1026

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

Signed-off-by: NBastian Blank <waldi@debian.org>

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.

Fixes #42544

Closes gitaly#946

Closes gitaly#929

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.