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: Bastian 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.

with StrongMemoize

Closes #41739

When a project uses fast-forward merging strategy user has
to rebase MRs to target branch before it can be merged.
Now user can do rebase in UI by clicking 'Rebase' button
instead of doing rebase locally.

This feature was already present in EE, this is only backport
of the feature to CE. Couple of changes:
* removed rebase license check
* renamed migration (changed timestamp)

Closes #40301