Fix Gitaly auto-detection caching

Closes #64802

See merge request gitlab-org/gitlab-ce!30954

(cherry picked from commit eb3f465e)

ec5ceae6 Fix Gitaly auto-detection caching

The GitalyClient held a lot of logic which was all very tightly coupled.
In this instance the feature logic was extracted to make it do just a
little less and create a bit more focus in the GitalyClient's
responsibilies.

We typically don't want to enforce request limits in production
However, we have some production-like test environments, i.e., ones
where `Rails.env.production?` returns `true`. We do want to be able
to check if the limit is being exceeded while testing in those
environments.

Backport of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7434

On HEAD~ we remove the ID from the class, which created a bug. Given we
don't need the ID anymore, it has been removed and simplified.

This reverts merge request !23229

This reverts merge request !23140

The disabling of Gitaly was basically stubbing `Feature.enabled?` call,
which was never triggered.

This will enable Geo to skip shards that not operational.

Relates to gitlab-org/gitlab-ee#4329

Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true

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

It seems that bad things happen when two gRPC stubs share one gRPC
channel so let's stop doing that. The downside of this is that we
create more gRPC connections; one per stub.

Closes gitaly#166