Our friends at GitHub show the programming languages for a long time,
and inspired by that this commit means to create about the same
functionality.

Language detection is done through Linguist, as before, where the
difference is that we cache the result in the database. Also, Gitaly can
incrementaly scan a repository. This is done through a shell out, which
creates overhead of about 3s each run. For now this won't be improved.

Scans are triggered by pushed to the default branch, usually `master`.
However, one exception to this rule the charts page. If we're requesting
this expensive data anyway, we just cache it in the database.

Edge cases where there is no repository, or its empty are caught in the
Repository model. This makes use of Redis caching, which is probably
already loaded.

The added model is called RepositoryLanguage, which will make it harder
if/when GitLab supports multiple repositories per project. However, for
now I think this shouldn't be a concern. Also, Language could be
confused with the i18n languages and felt like the current name was
suiteable too.

Design of the Project#Show page is done with help from @dimitrieh. This
change is not visible to the end user unless detections are done.

After trying to remove the whole method in
8f69014af2902d8d53fe931268bec60f6858f160, this is a more gentle
approach to the method. :)

Prior to this change, new commit detection wasn't implemented in Gitaly,
this was done through: https://gitlab.com/gitlab-org/gitaly/merge_requests/779

As the new implemented got moved around a bit, the whole RevList class
got removed.

Part of https://gitlab.com/gitlab-org/gitaly/issues/1233

This specific one isn't used on most machines, therefor low risk.

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

Various counters would expose either project names, or full project
paths (e.g. "gitlab-org/gitlab-ce"). This commit changes various places
where we use "add_event" so we no longer expose (potentially) private
information.

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

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: Bastian Blank <waldi@debian.org>

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

Fixes #42609