Add documentation & helper text about securing a GitLab installation

See merge request gitlab-org/gitlab!18987

This change adds more prominent documentation
for sign up restrictions.

Add link to Mermaid Live Editor

See merge request gitlab-org/gitlab!22389

Fix typo 'displosal' in merge request doc

See merge request gitlab-org/gitlab!22429

Upgrade json-jwt to v1.11.0

Closes #39148

See merge request gitlab-org/gitlab!22440

Simplify static-analysis count for ignored warnings

See merge request gitlab-org/gitlab!22448

This adds a minor performance optimization to avoid allocation of an
array.

Fix static-analysis failure due to caniuse-lite dependency

Closes #194788

See merge request gitlab-org/gitlab!22447

As seen in https://gitlab.com/gitlab-org/gitlab/-/jobs/394057944,
static-analysis is failing with:

```
Browserslist: caniuse-lite is outdated. Please run next command
`yarn upgrade`
```

The problem may be occurring because browserslist is detecting that
caniuse-list is approximately 6 months old and outputs a warning using
console.warn.

To fix this, we change static-analysis to filter this warning message
when deciding to exit with error code 2. Older GitLab backports
shouldn't fail because we need to upgrade this dependency.

Closes https://gitlab.com/gitlab-org/gitlab/issues/194788

This fixes CVE-2019-18848 and brings in a number of minor fixes:
https://github.com/nov/json-jwt/compare/v1.9.4..v1.11.0

Closes https://gitlab.com/gitlab-org/gitlab/issues/39148

Update sharing and permissions section

See merge request gitlab-org/gitlab!21954

Include info under Settings > General for each repo

Specify milestone assignment on Security Release MR template

See merge request gitlab-org/gitlab!22430

Plugins documentation: Update examples link

See merge request gitlab-org/gitlab!22421

Loosen Danger requirements for security MRs

See merge request gitlab-org/gitlab!22396

Security MRs in the `gitlab-org/security` group don't require merge
request IDs for changelog entries, nor do they have strict target branch
requirements.

Specifies that a closed milestone can be assigned through a merge
request via quick actions.

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/issues/610

Link merge requests for all non review app deploys

Closes #38000 and #38092

See merge request gitlab-org/gitlab!21254

Fix markdown table border colors

Closes #27884

See merge request gitlab-org/gitlab!22314

Use border color specified in Pajamas for markdown table borders

Fix bug when exposing non existing artifacts

See merge request gitlab-org/gitlab!22378

Fix a misspelling in sync-stable-branch script

See merge request gitlab-org/gitlab!22260

Gracefully handle CI lint errors in artifacts section

Closes #194069

See merge request gitlab-org/gitlab!22388

This changes how we link merge requests to deployments so that:

1. We link merge requests for any deployment that is not in the
   "created" state.
2. We do not link merge requests to review app deployments.

We want to link deployments regardless of their status so that we can
also show failed and running deploys in the merge request widget (and
perhaps in other places). We don't want to link review app deployments
since this is not useful, and may lead to deployments to different
review app environments showing up on a merge request page.

This builds on the refactoring of the deployment model introduced in
merge request https://gitlab.com/gitlab-org/gitlab/merge_requests/20474,
and moves the linking of merge requests to Deployments::FinishedWorker.
This worker is scheduled every time a deployment transitions to a
finished state.

As part of these changes we also change Deployment#link_merge_requests
so that it ignores any already linked merge requests. This way if a
deployment changes its status multiple times, we don't error with
duplicate key errors.

This fixes https://gitlab.com/gitlab-org/gitlab/issues/38092.

Add Index to help Hashed Storage migration on big instances

Closes #194066

See merge request gitlab-org/gitlab!22391

Use proper find targets in test

Closes #191269

See merge request gitlab-org/gitlab!22298

Wrap requests in an ApplicationContext

See merge request gitlab-org/gitlab!20791

Performance improvements on milestone burndown chart

See merge request gitlab-org/gitlab!22380

Prevent Gitaly N+1 queries in blob search

See merge request gitlab-org/gitlab!21996

Remove ActiveRecord patch to ignore limit on text columns

See merge request gitlab-org/gitlab!22406

Wrap emit calls to nextTick

Closes #38114

See merge request gitlab-org/gitlab!22323

Don't build up events array when checking if burndown chart
is empty or accurate. Preload issue project to avoid N+1 calls.

This provides context to all requests made to Rails controllers or
grape endpoints.

Doing this starts a new `Labkit::Context`, to which we can provide a
namespace, project and user.

We're currently setting the following values:

- Web requests: In the ApplicationController we wrap the entire
  request in a `with_context`.
  - user: based on the `auth_user` if there is one
  - project: We try to read the @project instance variable of the
    controller.
  - namespace: We try to read the @group instance variable of the
    controller. If there was none, but the project was set, we'll use
    that path to set the namespace

- API requests: The application context is pushed in a before block
  setting the following values:
  - user: to `current_user` if there is one
  - project: to `@project`
  - namespace: to `@group`

- Internal API requests: the application context is pushed in a before
  block:
  - user: When to the user set in `Api::Support::GitAccessActor`
  - project: to @project if it was available

The 3 supported attributes for a context are read lazily when
required.

This also replaces the existing correlation middlewares with the new
Labkit::Context middlewares.

The rack middleware wraps each rack request in an overarching context
that adds the correlation id. The context is cleaned up after the
request, so we're sure all child contexts are cleaned up as well.

The sidekiq client middleware will write the context into the job that
 goes into redis when a job is scheduled.

The sidekiq server middleware will then re-instantiate this context so
the job gets executed with the same context that was alive when it was
scheduled. This means that any new job scheduled from sidekiq would
also have this context.

This makes sure we're always working with the project that we've
validated access for.

Add Reenqueuer concern

See merge request gitlab-org/gitlab!22031

Add system/comment filter to notes api

See merge request gitlab-org/gitlab!21159

Add logging to error handling in ElasticIndexerWorker

See merge request gitlab-org/gitlab!22414