Created new API::Support::GitAccessActor class to
encapsulate some of the more edge logic, making
the /internal/allowed route much cleaner.

Instead of sending varied data to Gitaly, and making Gitaly construct
various messages, build the messages first and have Gitaly print
either basic messages or alert messages, in the order they come.

Depends on https://gitlab.com/gitlab-org/gitaly/merge_requests/1410

Suggests to use a JSON structured log instead

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102

`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

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.

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

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.

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).

Partially addresses #47424.

Had to make changes to spec files because
stubbing methods on frozen objects is a mess
in RSpec and leads to failures:

https://github.com/rspec/rspec-mocks/issues/1190

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

- Better gitaly-handling in /api/internal/allowed specs

And use .rubocop.yml to exclude paths we don't care,
rather than using the cop itself to exclude.

- Make single gitaly payload
- Add feature-flag specs to verify payload

This new param allows us to share project information between components
that don't share or don't have access to the same filesystem
mountpoints, for example between Gitaly and Rails or between Rails and
Gitlab-Shell hooks. The previous parameters are still supported, but if
found, gl_repository is prefered. The old parameters should be deprecated
once all components support the new format.

Refactored specs and added a post deployment migration to remove the activity users table.

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

This will be necessary when adding gitaly settings. This version
doesn't make any functional changes, but allows us to include this
breaking change in 9.0 and add the needed extra settings in the future
with backwards compatibility

add complete changelog for !8949