These were written in seconds but are supposed to be in
milliseconds. The total Gitaly time was wrong for the same reason.

Fix Peek on Puma

Closes #66528

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

Previously, we called the `peek_enabled?` method like so:

    prepend_before_action :set_peek_request_id, if: :peek_enabled?

Now we don't have a `set_peek_request_id` method, so we don't need that
line. However, the `peek_enabled?` part had a side-effect: it would also
populate the request store cache for whether the performance bar was
enabled for the current request or not.

This commit makes that side-effect explicit, and replaces all uses of
`peek_enabled?` with the more explicit
`Gitlab::PerformanceBar.enabled_for_request?`. There is one spec that
still sets `SafeRequestStore[:peek_enabled]` directly, because it is
contrasting behaviour with and without a request store enabled.

The upshot is:

1. We still set the value in one place. We make it more explicit that
   that's what we're doing.
2. Reading that value uses a consistent method so it's easier to find in
   future.

For each DetailedView subclass, we add a `warnings` array to:

1. The top-level response.
2. Each individual call under the `details` key.

We use the `.thresholds` hash on the DetailedView to determine what's a
warning. If that hash is empty (the default), then the warnings array
will always be empty.

In dev environments, Sidekiq was encountering the message:

Circular dependency detected while autoloading constant Gitlab::Profiler

This saves some overhead during normal usage.

Peek attempts to serialize results with `to_json`, which calls
`ActiveSupport::JSON`. If an object is passed to `to_json` that contains
instance variables, `ActiveSupport` will attempt to recursively traverse
all variables.

The problem is that we can get into an infinite loop if the instance
references to an instance that references to something else that points
back to the same instance.

To avoid this mess, we just call `to_s` on the object. It appears only
`Gitlab::Git::Repository` and `::Repository` are the culprits here.

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

1. The output isn't great. It can be hard to find hotspots and, even
   when you do find them, to find why those are hotspots.
2. It uses some jQuery-specific frontend code which we can remove now
   that we don't have this any more.
3. It's only possible to profile the initial request, not any subsequent
   AJAX requests.

This uses an ActiveRecord subscriber to get queries and calculate the
total query time from that. This means that the total will always be
consistent with the queries in the table. It does however mean that we
could potentially miss some queries that don't go through ActiveRecord.

Making this change also allows us to unify the response JSON a little
bit, making the frontend slightly simpler as a result.

Introduce a `DetailedView` base class, which is inherited by
the Gitaly, Redis, and Rugged views. This reduces code duplication.