Add client and developer documentation of the GraphQL API's limits

See merge request gitlab-org/gitlab!52280

Adds client and developer documentation for the GraphQL API's limits:

- Complexity
- Max page size
- Request timeout

Define experiment feature flag type

See merge request gitlab-org/gitlab!52855

Copy and empty %p fixes in Welcome page

See merge request gitlab-org/gitlab!52660

Add QA docs for running transient bug tests

See merge request gitlab-org/gitlab!52849

Debian Group and Project Distribution Components

See merge request gitlab-org/gitlab!51732

Improve overriding stages example

See merge request gitlab-org/gitlab!52808

Group performance bar SQL queries by location

See merge request gitlab-org/gitlab!52678

Remove docs references to old subscription tiers

See merge request gitlab-org/gitlab!52823

Refactor spam/recaptcha mutations/services for better captcha support

See merge request gitlab-org/gitlab!51537

Changing Gold to Ultimate in docs text

See merge request gitlab-org/gitlab!52845

Add visual reviews to starter list

See merge request gitlab-org/gitlab!52848

Improve Service Desk documentation about templates

See merge request gitlab-org/gitlab!51992

Add recent failures to test report

See merge request gitlab-org/gitlab!52606

* Move the render_recaptcha? method to the Spammable concern,
  so it can be used from both the controllers and GraphQL
  mutations.
* Refactor logic and method naming in mutation to make it
  explicit that the #resolve method's args parameter is
  being mutated before being passed to the service layer as
  params
* Introduce ServiceCompatibility concern, to DRY up and
  abstract mutation-layer concerns related to processing
  graphql mutation field params to be compatible with those
  expected by the service layer
* Rename SpammableMutationFields concern to CanMutateSpammable
  to be more consistently named with other concerns
* Move and refactor the snippet_spam feature flag to be in the
  service layer, and be less coupled to the implementation
  details of spam checking.

See https://gitlab.com/gitlab-org/gitlab/-/issues/217722
for more details.

Fix delete action for package tests

See merge request gitlab-org/gitlab!52718

Resolve "Project name to path conversion in API mangles dots"

See merge request gitlab-org/gitlab!52725

Moved vulnerability report to separate docs page

See merge request gitlab-org/gitlab!52749

Addressed duplication of vuln report section in security dashboard page

To abstract away from repeatedly accessing an
object's property, we'll add that property to a
computed prop so if we ever change that
property name it's just one spot that we need
to update.

Remove Silver and Gold tiers from user docs

See merge request gitlab-org/gitlab!52840

Add badges to H1 on Configure docs

See merge request gitlab-org/gitlab!51526

Add error handling to update member service

See merge request gitlab-org/gitlab!52014

Add descriptions to MilestoneStateEnum

See merge request gitlab-org/gitlab!52494

All pages need badging to indicate what products they are
applicable to.

Fix i18n link syntax on Repository Cleanup page

See merge request gitlab-org/gitlab!52529

Add incremental compiler to webpack dev server

See merge request gitlab-org/gitlab!52350

In order to have quicker compilations while developing we are adding an
incremental compiler to webpack to render routes on demand.

When the developer is working on the dev server and enables the
incremental compiler with DEV_SERVER_INCREMENTAL=true, the new
functionality is enabled.

The biggest problem to solve here: How can we _know_ which entry point
to render and which not? Our current webpack integration with rails
requires the webpack manifest to have a list of all existing entry
points. So our incremental compiler takes the following approach:

Every compilation of webpack will run `generateEntries` which generates
a list of all our entry points. In that function we are able to replace
all page specific entrypoints and point them to an empty file,
unless we explicitly want them to compile.

In the webpack-dev-server itself we register a middleware which keeps
track of all the page specific bundles requested. Whenever a page
specific bundle is requested that hasn't been requested before, we add
it to the list of bundles we want compiled.

This approach allows us to dynamically change the entry points without a
need to restart webpack alltogether _and_ it works with hot module
reloading.

Rather than pointing to a blank javascript we are pointing to one which
renders an overlay to let the user know that webpack compiles the page
for the first time.

Additionally we keep a history of requested routes in `tmp/cache` in
order to keep the list of compiled entry points between sessions. In a
next iteration we can add a bit of logic and e.g. remove entry points
the developer hasn't been visiting in a week.

First results are really promising (on my machine):
 - Memory consumption when idling: 1600MB => 340MB
 - Max memory: ~2200MB => ~1000MB
 - Initial Compilation time: 58s => 15s
 - Recompile afer a file change: 13s => 3s
 - Visiting a new page that hasn't been visited before, it takes about
   four seconds to reload the page, seven seconds to completely load the
   page.

Currently the technique still watches all of the source files, so
changing an unrelated file will trigger a recompilation. This is however
a minor caveat and the same behavior that we currently have, maybe we
can optimize in the future.

Add auto_delete_at to environments

See merge request gitlab-org/gitlab!52788

Apply new GitLab UI for input field in admin/broadcast_messages

See merge request gitlab-org/gitlab!52411

Pass the custom mapping fields to frontend

See merge request gitlab-org/gitlab!51982

Replaced bootstrap popover with GlPopover

See merge request gitlab-org/gitlab!49722