This deadline made it difficult to debug feature specs because any
Gitaly calls that were issued would fail after 57 seconds. We disable
this timeout during tests to make it easier to use a debugger.

Closes https://gitlab.com/gitlab-org/gitlab-development-kit/issues/882

The feature has been enabled on GitLab.com for over 24h without
issue.

It hasn't had the impact we hoped it would, but it does improve the
situation. And the calculated deadline can be reused in other parts of
the application that should enforce this limit.

Every time we check a feature flag using `Feature.enabled?` it could
return a different value based on the percentage that it's enabled
for.

So making sure we only call this value once per request, so we have a
consistent state for the entire request.

This makes sure that the deadline we set on a gitaly call never
exceeds the request deadline.

We also raise an exception if the request deadline has already been
exceeded by the time we're trying to make a Gitaly call.

These deadlines don't apply when calling gitaly from Sidekiq.

We do this by storing the start time of the request in the request
store on the thread (using the RequestStore).

The maximum request duration defaults to 55 seconds, as the default
worker timeout is 60 seconds. But can be configured through
gitlab.yml.

Auto-correct some references in RSpec as:
- expect_any_instance_of -> expect_next_instance_of
- allow_any_instance_of -> allow_next_instance_of

Related to https://gitlab.com/gitlab-org/gitlab/issues/34997

Ran: bundle exec rubocop --only RSpec/EmptyLineAfterSubject -a

Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758

The change in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24199 caused
requests coming from a load balancer to arrive as 127.0.0.1 instead of
the actual IP.

`Rack::Request#ip` behaves slightly differently different than
`ActionDispatch::Request#remote_ip`: the former will return the first
X-Forwarded-For IP if all of the IPs are trusted proxies, while the
second one filters out all proxies and falls back to REMOTE_ADDR, which
is 127.0.0.1.

For now, we can revert back to using `Rack::Request` because these
middlewares don't manipulate parameters. The actual fix problem involves
fixing Rails: https://github.com/rails/rails/issues/28436.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58573

As mentioned in
https://gitlab.com/gitlab-org/gitlab-ee/issues/9035#note_129093444,
Rails 5 switched ActionDispatch::Request so that it no longer inherits
Rack::Request directly. A middleware that uses Rack::Request to
read the environment may see stale request parameters if
another middleware modifies the environment via ActionDispatch::Request.
To be safe, we should be using ActionDispatch::Request everywhere.

As mentioned in
https://gitlab.com/gitlab-org/gitlab-ee/issues/9035#note_129093444,
Rails 5 switched ActionDispatch::Request so that it no longer inherits
Rack::Request directly. A middleware that uses Rack::Request to
read the environment may see stale request parameters if
another middleware modifies the environment via ActionDispatch::Request.
To be safe, we should be using ActionDispatch::Request everywhere.

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

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>

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

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

 - cleanup formating in haml
 - clarify time window is in seconds
 - cleanup straneous chunks in db/schema
 - rename count_uniqe_ips to update_and_return_ips_count
 - other