The original issue didn't specify this, but the code always allowed
reporters to do everything here. I think that's correct because

1. Developer permissions normally refer to code, and boards are to do
   with issues.
2. Reporters can manage epics, as well as labels on
   issues, which are in a similar space.

!22112 added the latest extension to this list, .log meaning
that this doc extension is valid for version >= 11.5

Closes #56801

This reverts commit 171818df.

JIT resource creation blocks deployments if a user is
self-managing their cluster, as it will fail the build
if unable to create a namespace and service account.

Using a custom namespace and service account was previously
supported for project level clusters, so we should preserve
this functionality.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27352

Remove redundancies:
- Domains
- User/group/project sites

This reverts commit 6c75bd01, reversing
changes made to 1be7f5aa.

Apparently one has to wait, but DNS can't be involved at this step. (As the DNS records had already to be ready and presumably propagated for the ACME challenge to work.) So let's assume it's the content delivery network serving the certificate that needs some time here.

This reverts commit a5378665.

Log events so that it's easy to see
when different requests are starting.

Set pages_domain.remove_at when disabling it
Add specs for marking pages domain for removal
Notify user that domain is being removed
Add documentation

MergeRequests::PushOptionsHandlerService has been updated to allow
creating and updating merge requests with the
`merge_when_pipeline_succeeds` set using git push options.

To create a new merge request and set it to merge when the pipeline
succeeds:

  git push -u origin -o merge_request.create \
    -o merge_request.merge_when_pipeline_succeeds

To update an existing merge request and set it to merge when the
pipeline succeeds:

  git push -u origin -o merge_request.merge_when_pipeline_succeeds

Issue https://gitlab.com/gitlab-org/gitlab-ce/issues/53198

To create a new merge request:

  git push -u origin -o merge_request.create

To create a new merge request setting target branch:

  git push -u origin -o merge_request.create \
    -o merge_request.target=123

To update an existing merge request with a new target branch:

  git push -u origin -o merge_request.target=123

A new Gitlab::PushOptions class handles parsing and validating the push
options array. This can be the start of the standard of GitLab accepting
push options that follow namespacing rules. Rules are discussed in issue
https://gitlab.com/gitlab-org/gitlab-ce/issues/43263.

E.g. these push options:

  -o merge_request.create -o merge_request.target=123

Become parsed as:

  {
    merge_request: {
      create: true,
      target: '123',
    }
  }

And are fetched with the class via:

  push_options.get(:merge_request)
  push_options.get(:merge_request, :create)
  push_options.get(:merge_request, :target)

A new MergeRequests::PushOptionsHandlerService takes the `merge_request`
namespaced push options and handles creating and updating
merge requests.

Any errors encountered are passed to the existing `output` Hash in
Api::Internal's `post_receive` endpoint, and passed to gitlab-shell
where they're output to the user.

Issue https://gitlab.com/gitlab-org/gitlab-ce/issues/43263

This commit updates the documentation about the
"Pipelines must succeed" checkbox.

Resolve "Add troubleshooting section to capture errors with installing applications to a Kubernetes cluster"

Updated the error message in the docs

Fixes quick actions add label when adding a label which name middle
word overlaps with another label name: for example adding "A B C" when
also label "B" exists.
With the fix only the label "A B C" is correctly added, previously
also the label "B" was added due to the middle word overlaps.

Updated the documentation to match the updated order including
the screenshot.