Changelog: fixed

When we moved the logic that wipes the Prometheus metrics
dir out of the Rackup file and into the initializer, all
Sidekiq workers would call this and potentially enter a
race condition where they deleted each other's database
files.

Changelog: fixed

GDK defaulted to `/` but that has issues with some gems because that is
not a valid relative root so we want to change the GDK default to an
empty string.

This changes our rackup file to handle a blank string properly.

Drops unicorn-worker-killer gem and related configs, code, docs.
Split from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61888.

Changelog: removed

Auto-corrected with Rubocop

After moving the multiproc dir cleanup into `config.ru`:`warmup`, we
stopped cleaning Sidekiq metrics dir which is not correct.
This MR intended to fix that. More details:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31668

When we hit our app with the initial request, in `warmup`,
some metrics already being created as well as corresponding files.
If we do `multiproc_file_dir` cleanup after that, we delete the files
from the dir while keeping them in memory which leads to the incorrect
behavior: the metric is being updated in in-memory, while is not present
in the db, not sent to Prometheus as the result.

This update has two important fixes:

1. It reverts the monkey patch introduced in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23385 since
https://github.com/rack/rack/pull/1201 is now part of the release.

2. Preserve forwarded IP address for trusted proxy chains
(https://github.com/rack/rack/pull/1343).

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

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

Rack with Unicorn is unable to handle chunked requests due to private `eof?` method.
This exposes `eof?` not changing `rack` behavior.

Issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/8539

These limits were updated in our docs, and in omnibus some time ago. But
the defaults in the source-install were missed.

after the request. This way, we could release the
project referred from the controller, which potentially
referred a repository which potentially allocated a lot of
memories.

Before this change, we could hold the last request data
and cannot release the memory. After this change, the
largest request data should be able to be collected from GC.

This might not impact the instances having heavy load,
as the last request should be changing all the time,
and GC won't kick in for each request anyway.

However it could still potentially allow us to free more
memories for each GC runs, because now we could free one
more request anyway.

This would make the application considered ready much slower,
but when it's ready, then it's really ready. Before this change,
it claims to be ready, but it's annoyingly slow for the first
request with GDK. It's 100% 502 for me, for the first request.

This shouldn't really affect production or so, because if it's
really ready, it should be blazingly fast, and it should not
slow things down too much.

The culprit here is probably `ActionController::Base.helpers.asset_path`
but this could make sure that anything else would load first, too.

+ Use NullMetrics to mock metrics when unused
+ Use method_missing in NullMetrics mocking
+ Update prometheus gem to version that correctly uses transitive dependencies
+ Ensure correct folders are used in Multiprocess prometheus client tests.
+ rename Sessions controller's metric

+ Add spaces for four phases approach
+ fix InfluxDB rename

metrics wip

This is a step for #29118.

Add a single metric to count successful logins.

Summary types are not supported so remove Collector.  Either
we need to support the summary type or we need to create a
multiprocess-friendly Collector.

Add config to load prometheus and set up the Collector and the
Exporter.

Fix `Gemfile` as current prometheus-client gemspec is missing the
`mmap2` dependency.

Using this limit on GitLab.com it appears we're able to reduce response
timings by about 620 milliseconds compared to the previous limit.

See gitlab-org/gitlab-ce!2421 for more information.

This makes it easier for users to use their own limits based on their
server configuration.

Don't assume that if the Rack server is not Passenger then it must be Unicorn. There are many other Rack servers in the world (uwsgi being one example that people use a lot).

The reverse check is much more logical, i.e. check explicitly for Unicorn

Conflicts:
	Gemfile.lock