Add FetchSourceBranch Gitaly call

Closes gitaly#758

See merge request gitlab-org/gitlab-ce!15498

[ci skip]

Update composite pipelines index to include "id"

See merge request gitlab-org/gitlab-ce!15519

default fill color for SVGs

See merge request gitlab-org/gitlab-ce!15476

ignore hashed repos (for now) when using `rake gitlab:cleanup:repos`

Closes #40291

See merge request gitlab-org/gitlab-ce!15520

Set the default gitlab-shell timeout to 3 hours

Closes #39977

See merge request gitlab-org/gitlab-ce!15292

Use Redis cache for branch existence checks

Closes #40349

See merge request gitlab-org/gitlab-ce!15513

Update CONTRIBUTING.md: Link definition of done to criteria

See merge request gitlab-org/gitlab-ce!15500

FileUploader should use Hashed Storage only when project is migrated

See merge request gitlab-org/gitlab-ce!15526

Simplify Feature Proposal template

See merge request gitlab-org/gitlab-ce!15297

Use arrays in Ci::Pipeline#latest_builds_with_artifacts

See merge request gitlab-org/gitlab-ce!15525

Use `make install` for Gitaly setups in non-test environments

See merge request gitlab-org/gitlab-ce!15295

Fix blank states using old css

Closes #40377

See merge request gitlab-org/gitlab-ce!15521

Add wiki css to help page

See merge request gitlab-org/gitlab-ce!15488

This updates the composite index on ci_pipelines (project_id, ref,
status) to also include the "id" column at the end. Adding this column
to the index drastically improves the performance of queries used for
getting the latest pipeline for a particular branch. For example, on
project dashboards we'll run a query like the following:

    SELECT ci_pipelines.*
    FROM ci_pipelines
    WHERE ci_pipelines.project_id = 13083
    AND ci_pipelines.ref = 'master'
    AND ci_pipelines.status = 'success'
    ORDER BY ci_pipelines.id DESC
    LIMIT 1;

    Limit  (cost=0.43..58.88 rows=1 width=224) (actual time=26.956..26.956 rows=1 loops=1)
      Buffers: shared hit=6544 dirtied=16
      ->  Index Scan Backward using ci_pipelines_pkey on ci_pipelines  (cost=0.43..830922.89 rows=14216 width=224) (actual time=26.954..26.954 rows=1 loops=1)
            Filter: ((project_id = 13083) AND ((ref)::text = 'master'::text) AND ((status)::text = 'success'::text))
            Rows Removed by Filter: 6476
            Buffers: shared hit=6544 dirtied=16
    Planning time: 1.484 ms
    Execution time: 27.000 ms

Because of the lack of "id" in the index we end up scanning over the
primary key index, then applying a filter to filter out any remaining
rows. The more pipelines a GitLab instance has the slower this will get.

By adding "id" to the mentioned composite index we can change the above
plan into the following:

    Limit  (cost=0.56..2.01 rows=1 width=224) (actual time=0.034..0.034 rows=1 loops=1)
      Buffers: shared hit=5
      ->  Index Scan Backward using yorick_test on ci_pipelines  (cost=0.56..16326.37 rows=11243 width=224) (actual time=0.033..0.033 rows=1 loops=1)
            Index Cond: ((project_id = 13083) AND ((ref)::text = 'master'::text) AND ((status)::text = 'success'::text))
            Buffers: shared hit=5
    Planning time: 0.695 ms
    Execution time: 0.061 ms

This in turn leads to a best-case improvement of roughly 25
milliseconds, give or take a millisecond or two.

This changes Ci::Pipeline#latest_builds_with_artifacts so it returns an
Array instead of a relation. Whenever we use this data we do so in two
steps:

1. Count the number of rows
2. If this number is greater than 0, iterate over the rows

By returning an Array instead we only execute 1 query of which the total
time/work is less than running either just a COUNT(*) or both queries
(in the worst case).

On GitLab.com this change should save us a few milliseconds per request
to ProjectsController#show.

Optimize read-only middleware so that it does not consume as much CPU

Closes #40185 and gitlab-com/infrastructure#3240

See merge request gitlab-org/gitlab-ce!15504

Skip confirmation user api

Closes #28934

See merge request gitlab-org/gitlab-ce!15175

Custom issue tracker

See merge request gitlab-org/gitlab-ce!15516

Resolve "Notes API for issues no longer returns label additions/removals"

Closes #39461

See merge request gitlab-org/gitlab-ce!15080

Resolve "TagsPage|Tags"

Closes #40367

See merge request gitlab-org/gitlab-ce!15512

This reverts commit 91075c82.

Batch load blobs for diff generation

Closes #37599

See merge request gitlab-org/gitlab-ce!15370

Fix promoting milestone updating all issuables without milestone

Closes #40337

See merge request gitlab-org/gitlab-ce!15487

After installing a new gem, batch-loader, a construct can be used to
queue data to be fetched in bulk. The gem was also introduced in both
gitlab-org/gitlab-ce!14680 and gitlab-org/gitlab-ce!14846, but those mrs
are not merged yet.

For the generation of diffs, both the old blob and the new blob need to
be loaded. This for every file in the diff, too. Now we collect all
these so we do 1 fetch. Three `.allow_n_plus_1_calls` have been removed,
which I expect to be valid, but this needs to be confirmed by a full CI
run.

Possibly closes:
- https://gitlab.com/gitlab-org/gitlab-ce/issues/37445
- https://gitlab.com/gitlab-org/gitlab-ce/issues/37599
- https://gitlab.com/gitlab-org/gitlab-ce/issues/37431