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.

This adds a database migration that creates routes for any projects and
namespaces that don't already have one. We also remove the runtime code
for dynamically creating routes, as this is no longer necessary.

Signed-off-by: Marko, Peter <peter.marko@siemens.com>

[ci-skip]

This reverts commit 1915c9f0.

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

This significantly improves performance when a user pushes many references.

project.path_locks.any? doesn't cache the output and runs `SELECT 1 AS one
FROM "path_locks" WHERE project_id = N` each time. When there are thousands
of refs being pushed, this can time out the unicorn worker.

CE port for https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6159.

Use data_source_exists? where possible instead of table_exists? in order to be Rails5 compatible

Before the push git would make a call to
`/:namespace/:project/git-receive-pack`. This would perform an access
check without a ref. So the `Project#branch_allows_maintainer_push?`
would return false.

This adjusts `Project#branch_allows_maintainer_push?` to return true
when passing no branch name if there are merge requests open that
would allow the user to push.

The actual check then happens when a call to
`/api/v4/internal/allowed` is made from a git hook.

The cache state for Wikis that were imported via GitHub or Bitbucket does
not appear to have been flushed after a successful import.

Closes #47546

"Maintainer" will be freed to be used for #42751

When deleting associated records, Rails loads all associations into memory
(https://github.com/rails/rails/issues/22510) before destroying them. This
can cause a surge in memory and cause destruction of objects to fail
due to idle in transaction database timeouts. This fix is inspired from
https://github.com/thisismydesign to destroy `has_many` relationships
in batches.

Closes #44610

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

ObjectStore uploader requires presence of associated `uploads` record
when deleting the upload file (through the carrierwave's after_commit
hook) because we keep info whether file is LOCAL or REMOTE in `upload`
object.

For this reason we can not destroy uploads as "dependent: :destroy" hook
because these would be deleted too soon. Instead we rely on
carrierwave's hook to destroy `uploads` in after_commit hook.

But in before_destroy hook we still have to delete not-mounted uploads
(which don't use carrierwave's destroy hook). This has to be done in
before_Destroy instead of after_commit because `FileUpload` requires
existence of model's object on destroy action.

This is not ideal state of things, in a next step we should investigate
how to unify model dependencies so we can use same workflow for all
uploads.

Related to #45425