`Gitlab::QueryLimiting.whitelist` has been moved from being inside the
feature flag conditional check to the `process_mr_push_options`
`Api::Internal` helper.

https://gitlab.com/gitlab-org/gitlab-ce/issues/60250

When creating a merge request for push options, there may be over 100
queries that are run to create a merge request. Even after we reduce the
number of queries by disabling the Sidekiq jobs, it appears we still
hover near this limit.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/11450

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

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.

Resolve CE to EE differences in the lib/api directory

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

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.