In this commit we track the edit action for the SSE, when an
MR is created through it. For that we track the request referer.

raw_diffs goes to gitaly, and can cause poor performance. This flag is
the first step in experimenting with accessing the diffs stored in the
DB.

This adds a feature category to API classes from G -> Discussions

This is the result of auto-correcting API/Base.

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

Move job variable and pipeline entities

This is the first step towards `UserAccess` being truly polymorphic. It
should accept any `HasRepository` instance.

Move it to the helper in order to DRY and reduce its complexity

This commit adds an extention to the pipeline creation service

They are required for implementing approvals in FOSS

With the BatchLoader implementation in the
`Gitlab::Entities::IssuableEntity` it was not necessary anymore to
sent this object around.

We added NOT functionality to the IssuableFinder and now expose that
through the Web UI. This MR adds the same negation functionality to the
Merge Request API.

This brings back many of the changes in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27276. This was
reverted due to some failures in the QA tests with nil parameters.

Grape v1.3.3 brings in Ruby 2.7 support and a number of fixes:
https://github.com/ruby-grape/grape/blob/master/CHANGELOG.md

1. Move all inherited `Grape::API` -> `Grape::API::Instance`
2. Remove use of Virtus since this has been removed from Grape.
3. Extract `Rack::Response` from API error
4. Grape v1.2.3 pulled in a fix used in `SafeFile`:
https://github.com/ruby-grape/grape/pull/1844, so we no longer need
to maintain our custom type.
5. Adapt `WorkhorseFile` with the latest changes to make custom types
work with Grape and dry-types.
6. Ensure `Array[String]` is coerced properly.

The change from Virtus to dry-types now requires all strings to be
coerced to arrays. Before this was done within Virtus.

7. Coerce `Array[Integer]` types to arrays of integers

8. Use a new helper, `coerce_nil_params_to_array!`, that coerces nil
Array inputs to empty arrays to preserve previous behavior.

If you have a parameter of type `Array[String]`, for example, Grape used
to coerce a provided `nil` value to `[]`. Grape no longer does this for
us, so we need a helper method that will automatically do this if the
parameter is present.

This merge request also introduces two Rubocop rules for Grape v1.3:

1. `Grape::API::Instance` instead of `Grape::API` is required, unless we
solve https://gitlab.com/gitlab-org/gitlab/-/issues/215230.

2. Grape parameters defined with `Array` types (e.g. `Array[String]`,
`Array[Integer]`) must have a `coerce_with` block or they will fail to
parse properly. See
https://github.com/ruby-grape/grape/blob/master/UPGRADING.md for more
details.

This was introduced "just in case", but we've had no complaints so now
is a good time to remove it.

When an MR is merged via the API without `should_remove_source_branch`
set, the branch is always retained, even if `force_remove_source_branch`
is set to true in the MR merge params. This was happening because the
API always passed a `should_remove_source_branch` with a `nil` value,
and `MergeService` interpreted this as `false`.

To fix this, we strip `nil` values from the `merge_params`.

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/219991

Turn IssuableMetadata concern into a class.
This refactoring allows EE only metadata to have its
logic on ee folder.

This MR alters the semantics of the mergeability check so the list API
does not enqueue rechecks by default. The previous behaviour can be
restored by use of a REST projection (`with_merge_status_recheck`).

Since the structure of the response remains the same, and even the
content of the returned response, this is not, strictly speaking, a
backwards-incompatible change. However, users who rely on this in the
list API will find they get stale data; rather than going to the single
MR endpoint, the projection gives them a way to specify that they need
the previous behaviour.

Longer-term, we should look at refreshing merge status independently of
any frontend actions. Since we can deduplicate sidekiq jobs now, the
best way to do that is probably to just enqueue a mergeability check
for every affected MR on push, and place strict limits on that sidekiq
queue's concurrency characteristics.

Add add_labels and remove_labels options

This reverts merge request !27276

This brings in Ruby 2.7 suport and a number of fixes:
https://github.com/ruby-grape/grape/blob/master/CHANGELOG.md

1. Move all inherited Grape::API -> Grape::API::Instance
2. Remove use of Virtus since this has been removed from Grape.
3. Extract Rack::Response from API error
4. Grape v1.2.3 pulled in a fix used in SafeFile:
https://github.com/ruby-grape/grape/pull/1844, so we no longer need
to maintain our custom type.
5. Adapt WorkhorseFile with the latest changes to make custom types work
with Grape and dry-types.
6. Ensure Array[String] is coerced properly.

The change from Virtus to dry-types now requires all strings to be
coerced to arrays. Before this was done within Virtus.

7. Coerce Array[Integer] types to arrays of integers

The change from Virtus to dry-types now requires all strings to be
coerced to arrays of integers. Before this was done within Virtus.

Only for getting a single merge request

This commit moves some required entities from controller to API level, and implements a limit on the number of context commits that will be returned from the API.

The param default value is true, returning
merge requests from non archived projects only.

* Let `skip_ci` to be passed to the API endpoint
* Add doc entry
* Add changelog entry

Refactored merge request API params into module.
Leveraged MergeRequestHelpers in Deployment API.
Updated Deployment API documentation.

When passing MWPS to the merge API, we should merge the MR immediately
when the pipeline already succeeded.

On the other hand, we should not merge the MR when passing MWPS and
the pipeline failed, even if the project allows merging with a failing
pipeline.

Expose description_html field for labels when with_labels_details
request parameter is set to true.

Expose issuable references in 3 options: short, relative and full.
Short and full aways display corresponding issuable reference,
while relative displays the reference depending on the context
from which it was referenced.

When the `merge_when_pipeline_succeeds` param is passed in,
an MR can be merged even when the pipeline has failed.

This change adds a check that prevents this from happening
when attempting to merge through the API

This compares the `MergeRequest#diff_head_sha` before squashing or
merging to a sha passed by the caller. If the `diff_head_sha` changed,
this means that the branch was updated since the merge was scheduled.

The `diff_head_sha` is the one passed to gitaly for merging or
squashing. So validating it right before performing the merge rather
than only in the controller would prevent the
`MergeRequests::RefreshService` from changing it between scheduling
the merge and actually merging.

Currently all the commits of a merge request is loaded
into the memory, converted to CommitCollection and
then paginated as an array

We can dramatically improve the performance by
paginating the diff commits first and then convert
this smaller array into CommitCollection

`MergeRequest#rebase_async` can lock indefinitely with a SELECT FOR
UPDATE call. If an update is idle in transaction or another rebase
attempts to run, `MergeRequest#rebase_async` could queue indefinitely or
until statement timeouts are triggered.

To limit the impact of this operation, we now just bail out after 5 s if
we can't get the lock. The user will see an error message if this
happens.

Part of https://gitlab.com/gitlab-org/gitlab/issues/30528

This changes any mention of gitlab-ce to gitlab-foss, and any mention of
gitlab-ee to just gitlab.

In the Merge Request view, under pipelines tab
the user can see a run pipeline button

Adds axios post request to button click

Adds the logic to handle the user click,
refresh the table and disable the button while thee
request is being made

Updates UI for desktop and mobile

Adds specs
Regenerates potfile

Follow-up after review

Uses .finally to avoid code repetition

In the Merge Request view, under pipelines tab
the user can see a run pipeline button

Adds axios post request to button click

Adds the logic to handle the user click,
refresh the table and disable the button while thee
request is being made

Updates UI for desktop and mobile

Adds specs
Regenerates potfile

Follow-up after review

Uses .finally to avoid code repetition

In MR https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14863 we
changed various prepend/include/extend lines to use the new X_if_ee
methods for injecting EE modules. Unfortunately, we forgot to take care
of a variety of lines due to the use of inaccurate patterns to find
these lines.

This commit takes care of moving over the remaining lines, except for
any prepend lines in the ee/ directory as the changes are not needed
there (since this directory is only available in EE).

This MR introduces tracking of the `rebase_jid` for merge requests. As
with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
rebase is proceeding in sidekiq.

After one release, we should remove the Gitaly-based lookup of rebases.
It is much better to track this kind of thing via the database.

This MR introduces tracking of the `rebase_jid` for merge requests. As
with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
rebase is proceeding in sidekiq.

After one release, we should remove the Gitaly-based lookup of rebases.
It is much better to track this kind of thing via the database.