Merge branch '29713-update-documentation-to-reflect-prometheus-monitors-k8s-by-default' into 'master'

Update docs to indicate prometheus k8s monitoring is on by default

See merge request !10089

Update deploy keys documentation

See merge request !10084

Add closed_at field to issues

Closes #27212

See merge request !9977

Remove repeated routes.path check for postgresql database

See merge request !10063

Fix Project Wiki update

Closes #29405

See merge request !9990

Use google-protobuf 3.2.0.2

See merge request !10014

Update 8.12-to-8.13.md: gitlab version 8.13 wants gitlab-shell v3.6.7

See merge request !10071

Todos performance: Include associations in Finder

See merge request !10076

Fix regressions introduced while adding CI endpoints in API v4

See merge request !9952

Allow dot in branch name in trigger/builds endpoint in API

Closes #29438

See merge request !10001

Allow creating merge request even if target branch is not specified in query params

Closes #28890

See merge request !9968

Allow unauthenticated access to some Branch API GET endpoints

Closes #29662

See merge request !10077

In APIv1 we've been sending all jobs from previous stages and
a `dependencies` list with names of jobs that user want to download
artifacts from. This was selected on Runners side.

In APIv1 we've planned to send only jobs that were defined (if any; and
all previous jobs by default). However I've missed the fact that
it was Runner who selected jobs, not GitLab. And now current version
of APIV4 sends all jobs everytime.

This commit fixes this. If user will define `dependencies` in his job,
then GitLab will send only selected jobs.

Artifacts download for authorization is using a job token of job to
which the artifact belongs. In APIv1 the token was sent with dependent
jobs details and in APIv4 it was designed to also contain it.

However I forgot about this parameter while working on
`/api/v4/jobs/request` endpoint.

This commit adds a missing parameter which is required for APIv4 to work
properly.

In Runner v1.3.0 we've started to send User-Agent header with Runner's
version data. Since GitLab v8.12.0 we've started to use this header to check
if used Runner's version supports 204 status code instead of 404 as a
response when there is no jobs to execute by a Runner.

In APIv4 (introduced in GitLab 9.0.0) will require Runner v9.0.0. And
writing more accurately: GitLab Runner v9.0.0 will require GitLab at
least 9.0.0. Because of such breaking change we are able to switch
entirely to 204 response code and there is no need to do check of
User-Agent.

This commit removes useless code and complexity.

In APIv1 we were using UpdateJob to verify if the runner exists. It was
the only method that was using Runner's token and used in special way
had no side effects (like scheduling a new job or unregisterring a
Runner).

In APIv4 we've change UpdateJob to use job's token as authentication
credentials, and that way we've removed the only endpoint that could
be used to verify if the Runner with a certain token exists in target
GitLab installation.

This commit adds `POST /api/v4/runners/verify` endpoint whose only
responsibility is to respond if Runner with posted credentials exists or
not.

Signed-off-by: Rémy Coutable <remy@rymai.me>

See merge request !9623.
Signed-off-by: Rémy Coutable <remy@rymai.me>

Rename 'All issues' to 'Open issues' in Add issues modal

Closes #29617

See merge request !10042

don't show loading spinners for server-rendered sidebar fields

Closes #24683

See merge request !9983

All CI offline migrations

See merge request !9730

26236 Change gfm textarea to use monospace font

Closes #26236

See merge request !10021

add changelog entry

Remove width from nav links

Closes #29586

See merge request !10051