The intention of this test is to ensure that the service class
MergeRequests::PushOptionsHandlerService does not run when the
:mr_push_options feature flag is disabled.

This test was passing, however was not testing what it was supposed to
be!

For one, setting Feature.disable(:feature) in the test does not disable
the feature, as rspec config in spec_helper stubs Feature to make all
features enabled:

https://gitlab.com/gitlab-org/gitlab-ce/commit/3ee48e422defaedd69946c607bd8d3672e510375

So the feature was still enabled in the test.

But this test wasn't failing because unfortunately I had put:

```
expect(MergeRequests::PushOptionsHandlerService).to receive(:new)
```

instead of not_to!

This meant that the `.new` method was being stubbed, so the service
class did not create a MergeRequest, which satisfied the second
expectation.

```
expect(MergeRequests::PushOptionsHandlerService).to receive(:new)
```

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

Exceptions are no longer raised, instead all errors encountered are
added to the errors property.

MergeRequests::BuildService is used to generate attributes of a new
merge request.

Code moved from Api::Internal to Api::Helpers::InternalHelpers.

Previously the raw push option Array was sent to Pipeline::Chain::Skip.

This commit updates this class (and the chain of classes that pass the
push option parameters from the API internal `post_receive` endpoint to
that class) to treat push options as a Hash of options parsed by
GitLab::PushOptions.

The GitLab::PushOptions class takes options like this:

    -o ci.skip -o merge_request.create -o merge_request.target=branch

and turns them into a Hash like this:

    {
      ci: {
        skip: true
      },
      merge_request: {
        create: true,
        target: 'branch'
      }
    }

This now how Pipeline::Chain::Skip is determining if the `ci.skip` push
option was used.

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

Bob Van Landuyt :neckbeard: authored 5 years ago and Douwe Maan committed 5 years ago

This makes sure that we always have a repository type when trying to
parse a repository from a path.

This is needed because sometimes we want to perform access checks as
if the project already existed, for example when creating a project on
push.

Before this we were only doing that when accessing git over http, this
makes sure it also works correctly when accessing git over SSH

Currently a no-op for CE

This changes the repository type from a binary `wiki?` to a type. So
we can have more than 2 repository types.

Now everywhere we called `.wiki?` and expected a boolean, we check
that type.

The repository_path is no longer needed since
https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/231, which closes
https://gitlab.com/gitlab-org/gitlab-shell/issues/135.

Instead of mixing in the shared secret into the querystring or body,
we could also specify it in a header.

The behavior for GitLab shell calling `/discover` when a user is not
found is currently untested.

We are relying on this behaviour to make GitLab reply "Welcome to
GitLab, Anonymous!".

This will enable us to track the human-readable project path with SSH
access in gitlab-shell. Currently the Gitaly logs will only show the
hashed storage and gl_repository path (e.g. project-1234).

When using git-lfs with SSH we weren't passing in
the expires_header header which is allows large
transfers to succeed in the event the current
default of 30 mins expires.

https://github.com/git-lfs/git-lfs/blob/master/docs/api/server-discovery.md#ssh

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

gitlab-org/gitlab-shell!166 added support for collecting push options
from the environment, and passing them along to the
/internal/post_receive API endpoint.

This change handles the new push_options JSON element in the payload,
and passes them on through to the GitPushService and GitTagPushService
services.

Futhermore, it adds support for the first push option, ci.skip.  With
this change, one can use 'git push -o ci.skip' to skip CI pipe
execution. Note that the pipeline is still created, but in the "skipped"
state, just like with the 'ci skip' commit message text.

Implements #18667

Updates specs to use new rails5 format.

The old format:
`get :show, { some: params }, { some: headers }`

The new format:
`get :show, params: { some: params }, headers: { some: headers }`

This reverts commit 00acef43.

This reverts commit 22954f22

LfsToken::HMACToken#token_valid?() will be examined and if false, look
in redis via LfsToken::LegacyRedisDeviseToken#token_valid?().

This reverts merge request !22526

Whenever a git push takes more than 50 seconds the user
will receive a trace from each check performed along with
their timings

If user has configure the setting then it will be passed to gitlab-shell
and gitlab-workhorse

- Use proper HTTP codes for /api/v4/allowed response
- CustomAction support

System hooks were not being triggered when projects were archived or
unarchived. Reuse the Projects::UpdateService to automatically
trigger system hooks and increase code reuse.

Why and how to enable this is covered in the docs being changed
here. This requires gitlab-org/gitlab-shell@2e8b670 ("Add support for
SSH certificate authentication", 2018-06-14) which has been merged in
and tagged as 8.0.0, so GITLAB_SHELL_VERSION needs to be bumped.

Merging this closes gitlab-org/gitlab-ce#34572 see
gitlab-org/gitlab-shell!207 for the gitlab-shell MR.

Implementation notes:

 - The APIs being changed here are all internal, and their sole
   consumer is gitlab-shell.

 - Most of the changed code is a MR to gitlab-shell, see the
   gitlab-org/gitlab-shell!207 MR. That change covers why only some of
   the internal methods get a new "username" parameter, and why some
   others only get a "user_id".

Rails 5 fix unknown keywords: changes, key_id, project, gl_repository, action, secret_token, protocol

This isn't a requirement, and removes deprecated method calls