Extend the Performance Bar with a button to profile the endpoint

Goal

The goal is to extend the Performance Bar with a button, which when clicked, will reload the page with profiling enabled and render the results in a flamegraph.

We already have all the building blocks in place:

1. We already support the above functionality, but it is hidden behind a not-very-accessible interface, which is to manually add a "secret" query parameter: https://docs.gitlab.com/ee/development/profiling.html#speedscope-flamegraphs. A better interface would be to use the Performance Bar itself to offer that option.
2. The backend for this is implemented in a Rack middleware: https://gitlab.com/gitlab-org/gitlab/blob/34a847aa1d2969f2b46a89120b318c2cfd802897/lib/gitlab/middleware/speedscope.rb
3. The frontend is a Vue component: https://gitlab.com/gitlab-org/gitlab/blob/d6b85a6ecd5626b8f7146a7af76ff5521233a636/app/assets/javascripts/performance_bar/components/performance_bar_app.vue

MVC / completion criteria

• A button or link replaces the manually entered query parameter
• Documentation is updated, maybe a screenshot would be nice 🤓

References

• speedscope - visualizes profiling data from various sources
• stackprof - the Ruby profiler we most commonly use
• !61332 (merged) could be a useful example for how to extend Performance Bar features.

Stretch goals

If time allows, I think it would be nice to consider the following improvements:

• The current implementation only allows pulling profiles based on wall time (it uses stackprof). It would be nice to have the option to pull a cpu or object profile instead. See https://docs.gitlab.com/ee/development/performance.html#production for which modes are supported.
• We have an alternative way of profiling worker processes, which is to sample CPU or object allocations over time for a given worker process (Puma or Sidekiq): https://gitlab.com/gitlab-org/gitlab/blob/627065cea6f114d3093eaf853bcfbd9f5c14f85d/lib/gitlab/stack_prof.rb. This currently requires a developer to have access to the given node and signal the process being profiled. Can we think of/propose (not necessarily implement) a solution for how we can unify all of these different ways to profile our app?