Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).

- Remove `FeatureConstrainer` call wrapping api endpoint
- Remove `Feature.enabled?(:graphql)` conditionals in back and frontend
- Modify graphql test to be graphql flag agnostic
- Remove api routing spec
- Remove frontend feature flag via `gon`

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

On all the issue lists -- Group, Project and Dashboard -- this
change adds a new option for managing the lists.

"Manual Ordering" option is added which when flipped on will allow
an user to drag and drop issues around to create a relative ordering
among them.

to support manual sorting on the frontend

We rewrote Related MRs widget using Vue.
The previous implementation was using Haml templates
and calling referenced_merge_requests endpoint which is
now deprecated. This MR deletes leftover stuff them.

- concerns
- dashboard
- groups
- import

Guest user of a project should not see branches

In order to have an accurate date about the last activity of a User
we need to update the last_activity_on field when the User is visiting
some basic pages of GitLab like pages related to Dashboards, Projects,
Issues and Merge Requests

Removes special error message when creating new issues

and whitelist the `update_task` parameter

In order to let users' sorting preferences transfer between devices, we
save the preference for issues and MRs (one preference for issues, one
for MRs) in the backend inside the UserPreference object

Removes special error message when creating new issues

Also remove test for the feature flag

Also changes old calls to the service

Process CSV uploads async using a worker then email results

Added button and modal to accept CSV file for uploading

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/55166

[master] Resolve "Personal access token with only `read_user` scope can be used to authenticate any web request"

See merge request gitlab/gitlabhq!2583

This suggests possibly related issues when the user types a title.

This uses GraphQL to allow the frontend to request the exact
data that is requires. We also get free caching through the Vue Apollo
plugin.

With this we can include the ability to import .graphql files in JS
and Vue files.
Also we now have the Vue test utils library to make testing
Vue components easier.

Closes #22071

Moves the related_branches method from Issue model
to RelatedBranchesService

Enables frozen string for some vestigial files as
well as the following:

* app/controllers/projects/**/*.rb
* app/controllers/sherlock/**/*.rb
* app/controllers/snippets/**/*.rb
* app/controllers/users/**/*.rb

Partially addresses #47424.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

These methods don't really need to be on the Issue model. Issue#related_branches
can also be moved to a service, but we can do that in a separate commit.

This commit does not change any behaviour; it just moves code around, renames
the service, and refactors the specs.

The status is shown for
- The author of a commit when viewing a commit
- Notes on a commit (regular/diff)
- The user that triggered a pipeline when viewing a pipeline
- The author of a merge request when viewing a merge request
- The author of notes on a merge request (regular/diff)
- The author of an issue when viewing an issue
- The author of notes on an issue
- The author of a snippet when viewing a snippet
- The author of notes on a snippet
- A user's profile page
- The list of members of a group/user

With text/calendar as Content-Type, the browser always downloads the
content as a file (even ignoring the Content-Disposition header). We
want to display the content inline when accessed from GitLab, similarly
to the RSS feed.

This could only be possible for users that can create merge requests
within a project.

So they need to be a allowed to create a branch and create a merge request.

So we can distinguish between the permissions on the source and the
target project.

- `create_merge_request_from` indicates a user can create a merge
  request with the project as a source_project
- `create_merge_request_in` indicates a user can create a merge
  request with the project as a target_project