This updates redirected links in integration, update, user
and workflow dirs. Should now link to final URLs to avoid
redirect hops

Previously, we used brackets to denote the tier badges,
but this made Kramdown, the docs site Markdown renderer,
show many warnings when building the site. This is now
fixed by using parentheses instead of square brackets.

This was caused by [PREMIUM] looking like a link to
Kramdown, which couldn't find a URL there.

See:
- https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/484
- https://gitlab.com/gitlab-org/gitlab-ce/issues/63800

After review, heading was changed and links to
it needed to be updated, and minor tweaks to
the issues docs such as note formatting

Add backticks around square brackets, or fix links, as necessary.

When a user sets only_allow_merge_if_pipeline_succeeds, also named
as "Pipeline must succeed" project setting, we require the pipeline
to be present.

This solves race condition issues especially with external CI
providers when a build is triggered externally but no pipelines are
created in GitLab yet.

Document that a head pipeline is expected when using "Pipeline
must succeed" setting. Also explain limitations with the use of
only/except where there may not be any jobs created and the merge
request will not be allowed to be merged.

Also adds and one linting rule
and makes project conform to it.

- Edit pages under user/project/merge_requests and
  add the relevant types in the frontmatter.
- Clean up descriptions.

Based on https://gitlab.com/groups/gitlab-org/-/epics/1280

Signed-off-by: NWilliam Desportes <williamdes@wdes.fr>

This feature was introduced in 12.0, not in 11.11.

This backports API and quick action docs.

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.

- Also has other minor improvements.

this is to match `git branch -D` from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23966
This just documents the change

- Also makes other minor Markdown fixes that were near the main fixes.