Draft: Cache git access on download commands

Why

Related to: #553981 (closed) but let me recap here.

We want to improve latency around Repositories::GitHttpController#git_upload_pack especially under load. During the investigation I noticed that Git protocol means we're going to make 2 requests to this controller on git pull/git clone. The first request goes to Repositories::GitHttpController#info_refs, followed by an immediate subsequent request to Repositories::GitHttpController#git_upload_pack.

What

If we cache the access check on a very short (10 seconds) TTL from the first request and construct the cache key well, the 2nd request could get the access check result from a the short lived cache instead of performing the work again.

This MR explores how it might be done and rolled out.

About the feature flag and rollout

We want to roll out caching access checks by actor, so that we can roll it out gradually. See https://docs.gitlab.com/development/feature_flags/#feature-actors

Actors in this file can be a different entities so we are not guaranteed a consistent concept like "user" or "project" that we can use as a feature actor, because those things might not exist.

The simplest way we can ensure a consistent rollout is to make a specific actor's existence a pre-condition to checking the Feature Flag's status. For example, we can check if a project exists and if the FeatureFlag is enabled for that project.

This means when we have the feature flag rolled out 100%, it will still only apply when projects are present.

To fully roll out the caching mechanism incrementally, we'll need to add a feature flag for each type of actor.

We will need a different strategy for rolling out to ci.

Related to #553981 (closed)