[11.5] Security extract pages with rubyzip

See merge request gitlab/gitlabhq!2835

(cherry picked from commit 75d595e1d29f3a4141b150e32ea5c592aa0a4270)

46885a07 Extract GitLab Pages using RubyZip
d2bd5db8 Fix Gemfile.rails5.lock

This new endpoint allow users to update a submodule's reference.

The MR involves adding a new operation RPC operation in gitaly-proto
(see gitlab-org/gitaly-proto!233) and change Gitaly to use this
new version (see gitlab-org/gitaly!936).

See gitlab-org/gitlab-ce!20949

This squelches the following warning:

warning: parser/current is loading parser/ruby24, which recognizes
warning: 2.4.4-compliant syntax, but you are running 2.4.5.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

Reverting https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15734 .
We are not using asset sync currently.

This allows us (and others) to test drive Puma without it affecting all
users. Puma can be enabled by setting the environment variable
"EXPERIMENTAL_PUMA" to a non empty value.

It looks like gRPC may have worked around
https://github.com/google/protobuf/issues/4210 via
https://github.com/grpc/grpc/pull/14634.

This is needed to support Ruby 2.5
(https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22555).

Removing this dependency also allows us to remove a transitive
dependency on gitlab_grit - which is the whole point of this exercise.

I don't think we can EOL gitlab_grit until it's removed as a dependency
from gitaly-ruby, but this at least gets it out of gitlab-ce.

This allows us to avoid one transitive dependency on gitlab-grit. The
aim is to remove all transitive dependencies.

This saves about 128 MB of baseline RAM usage per Unicorn and
Sidekiq process (!).

Linguist wasn't detecting languages anymore from CE/EE since
9ae8b574. However, Linguist::BlobHelper
was still being depended on by BlobLike and others.

This removes the Linguist gem, given it isn't required anymore.
EscapeUtils were pulled in as dependency, but given Banzai depends on
it, it is now added explicitly.

Previously, Linguist was used to detect the best ACE mode. Instead,
we rely on ACE to guess the best mode based on the file extension.

See: https://github.com/libgit2/libgit2/releases

Upgrade to latest version the following gems:
* Spring
* Bootsnap
* Thin
* webpack-rails
* pry-rails

Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.

Implements list_last_commits_for_tree to communicate with the
ListLastCommitsForTree Gitaly RPC

Bumps the Gitaly server version

Bumps the Gitaly-Proto gem version

We remove this feature as it never worked properly

The reason for removing this gem is that it's not being maintained
anymore. It uses `alias_method_chain` which is deprecated in rails 5
(and removed in 5.1), the issue is pending upstream (including
a fix) - https://github.com/suranyami/peek-sidekiq/issues/3 for a while.

Peek-sidekiq is used in performance bar for displaying sidekiq
statistics.

See
https://github.com/ruby-grape/grape/blob/master/CHANGELOG.md#110-842018.

This fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/51299

.

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

The most significant change in this version is that the default
concurrency has been lowered from 25 to 10 (https://github.com/mperham/sidekiq/issues/3892).
This doesn't affect omnibus-gitlab because the concurrency is controlled via a
setting that defaults to 25 anyway and is passed in via the `-c` command-line
parameter.

However, source installations (including the GDK) will have to either specify
the concurrency in `sidekiq.yml` or use the `-c` option.

Full list of changes: https://github.com/mperham/sidekiq/blob/master/Changes.md

We used to apply this limitation on GitLab when using Rugged. Now that
we've shifted to Gitaly, this parameter needs to be sent via a RPC
request. Currently this value is hardcoded on Gitaly.

There were several issues:

1. With Google Cloud Storage, we can't override the Content-Type with
Response-Content-Type once it is set.  Setting the value to
`application/octet-stream` doesn't buy us anything. GCS defaults to
`application/octet-stream`, and AWS uses `binary/octet-stream`. Just remove
this `Content-Type` when we upload new files.

2. CarrierWave and fog-google need to support query parameters:
https://github.com/fog/fog-google/pull/409/files, https://github.com/carrierwaveuploader/carrierwave/pull/2332/files.
CarrierWave has been monkey-patched until an official release.

3. Workhorse also needs to remove the Content-Type header in the request
(https://gitlab.com/gitlab-org/gitlab-workhorse/blob/ef80978ff89e628c8eeb66556720e30587d3deb6/internal/objectstore/object.go#L66),
or we'll get a 403 error when uploading due to signed URLs not matching the headers.
Upgrading to Workhorse 6.1.0 for https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/297
will make Workhorse use the headers that are used by Rails.

Closes #49957

Full list of changes: https://github.com/fnando/browser/blob/master/CHANGELOG.md

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

This is needed to support query parameters in `Fog::Storage::Google`.
See https://github.com/fog/fog-google/pull/409.

Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/49957

See https://github.com/libgit2/libgit2/releases for more details.