Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

This fixes gitlab-org/gitlab-ce#49953, as noted in the documentation
this feature is intended to be used when SSH certificates are
enabled. Then this warning becomes not only pointless, but also
misleading.

This builds on top of gitlab-org/gitlab-ce!21009 since both need to
modify the same documentation, which avoids a merge conflict.

See also the gitlab-org/gitlab-ce#49218 issue and associated merge
request.

This method is unneeded given its been pushed to Gitaly, through
https://gitlab.com/gitlab-org/gitaly/merge_requests/780

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

For master->maintainer permission rename

The partial using this cache key was showing stale information due to
the cache not being invalidated.

Resolve "Operations navigation menu renders empty menu when user does not have the right permissions"

LFS can be enabled and disabled per project using the API by Masters
and Owners, but the UI is only available to Admins. The interface and
API should be consistent.

LFS can also be enabled and disabled per group using the API by Owners,
but the UI is only available to Admins. This interface should also be
consistent.

Additionally removes an unneeded check if 2FA interface, since the
interface is only available to Owners.

Closes #33320

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

Closes #28857

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Whenever we already deal with a User object, let's use the more specific
method avatar_icon_for_user.

This was caused by the `@projects` value being empty when the current
user does not have any personal projects.

Whenever you push to a branch GitLab will show a button to create a
merge request (should one not exist already). The underlying code to
display this data was quite inefficient. For example, it involved
multiple slow queries just to figure out what the most recent push event
was.

This commit changes the way this data is retrieved so it's much faster.
This is achieved by caching the ID of the last push event on every push,
which is then retrieved when loading certain pages. Database queries are
only executed if necessary and the cached data is removed automatically
once a merge request has been created, or 2 hours after being stored.

A trade-off of this approach is that we _only_ track the last event.
Previously if you were to push to branch A and B then create a merge
request for branch B we'd still show the widget for branch A. As of this
commit this is no longer the case, instead we will only show the widget
for the branch you pushed to most recently. Once a merge request exists
the widget is no longer displayed. Alternative solutions are either too
complex and/or too slow, hence the decision was made to settle for this
trade-off.

Performance Impact
------------------

In the best case scenario (= a user didn't push anything for more than 2
hours) we perform a single Redis GET per page. Should there be cached
data we will run a single (and lightweight) SQL query to get the
event data from the database. If a merge request already exists we will
run an additional DEL to remove the cache key.

The difference in response timings can vary a bit per project. On
GitLab.com the 99th percentile of time spent in User#recent_push hovers
between 100 milliseconds and 1 second, while the mean hovers around 50
milliseconds. With the changes in this MR the expected time spent in
User#recent_push is expected to be reduced down to just a few
milliseconds.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/35990