We were looking these up on each request to an issue page, because the form is
pre-filled, as is the template dropdown. That was unnecessary: we could just
treat these as 'special' repository files (like the rendered README) and cache
them in Redis until they change on a push.

`Repository#has_visible_content?` used to rely on the cached count of local branches, but
since it is now an independently cached value it needs to be invalidated on its own.

Closes #38646

Allow n+1s caused by avatar fetches on the project dashboard. See https://gitlab.com/gitlab-org/gitlab-ce/issues/38261

See:
* https://www.kernel.org/pub/software/scm/git/docs/git-replace.html
* https://git-scm.com/book/en/v2/Git-Tools-Replace

This method was moved to ::Git but it is not cached there which causes performance problems

- `Gitlab::Shell.fetch_remote` now takes a `Gitlab::Git::Repository` instead

So it's more clear what could happen. Also add
more tests about the behaviour.

So that whenever we want to reserve more, we're aware,
and don't mess it up.

so that with_repo_branch_commit can properly short-circuit

The list of commits must be generated from the merge request,
not from a diff of the branches.

An upcoming update to rubocop-gitlab-security added additional
violations.

Store the original commit in the commit message. In case of
merge commit, the commits added to the start branch are also
listed.

so that we don't have to fetch it for non-forks

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13416#note_37193731

So we just try a cheaper way to detect it if it works or not