- Move some specs into contexts
- Let get_slugs method take a parameter and return a specific slug.
- Add rescues when using Addressable::URI.

The API get projects/:id/traffic/fetches allows user with write
access to the repository to get the number of clones for the
last 30 days.

The repository charts page used to detect the repository language for
each request that was made to the page. Given the detection is an
expensive operation and the same data is stored in the database the
database is now serving the request.

The same goes for an API endpoint that serves the languages.

When a repository is empty or non-existent the languages will always be
empty. And the language detection RPC isn't requested.

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

Prevent unauthorized users having access to milestone titles
through autocomplete endpoint.

Move remove_pages permission to maintainer
Fix before_action in pages controller to check `remove_pages`
permission
Add specs

Fixes a master failure due to a reduction in
the accepted Gitaly query count.

These specs were flaky and only passing after a retry due to how
rspec-retry works.

1. The test with paths that don't exist was returning 200 on the first
  try, then 404 on the second, not because the paths don't exist, but
  because the MR IID didn't change, thus the MR couldn't be found.
  I decided to remove the test entirely since we don't seem to return
  404 for paths that don't exist.
2. The test with a user that cannot view the merge request was failing
  the first time because the project owner wasn't removed with
  `project.team.truncate`.
  Changing the `let(:user)` to `create(:user)` and calling
  `project.add_maintainer(user)` in the `before` block fix the test.
Signed-off-by: NRémy Coutable <remy@rymai.me>

I think these two have been have been replaced with the `logs_tree`
endpoint

refactors the ui for diverging commits so that it's only a single
bar instead of two separate bars

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

Allow single tasks to be updated quickly

Add changelog

Rename word to query

User hash for limit

Do not allow control limit

Rename pluck names and add more specs

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

LFS uploads are handled in concert by workhorse and rails. In normal
use, workhorse:

* Authorizes the request with rails (upload_authorize)
* Handles the upload of the file to a tempfile - disk or object storage
* Validates the file size and contents
* Hands off to rails to complete the upload (upload_finalize)

In `upload_finalize`, the LFS object is linked to the project. As LFS
objects are deduplicated across all projects, it may already exist. If
not, the temporary file is copied to the correct place, and will be
used by all future LFS objects with the same OID.

Workhorse uses the Content-Type of the request to decide to follow this
routine, as the URLs are ambiguous. If the Content-Type is anything but
"application/octet-stream", the request is proxied directly to rails,
on the assumption that this is a normal file edit request. If it's an
actual LFS request with a different content-type, however, it is routed
to the Rails `upload_finalize` action, which treats it as an LFS upload
just as it would a workhorse-modified request.

The outcome is that users can upload LFS objects that don't match the
declared size or OID. They can also create links to LFS objects they
don't really own, allowing them to read the contents of files if they
know just the size or OID.

We can close this hole by requiring requests to `upload_finalize` to be
sourced from Workhorse. The mechanism to do this already exists.

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

Adds to search ILIKE search for milestones title in:
  - Milestones dashboard
  - Group milestones page
  - Project milestones page

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

LFS uploads are handled in concert by workhorse and rails. In normal
use, workhorse:

* Authorizes the request with rails (upload_authorize)
* Handles the upload of the file to a tempfile - disk or object storage
* Validates the file size and contents
* Hands off to rails to complete the upload (upload_finalize)

In `upload_finalize`, the LFS object is linked to the project. As LFS
objects are deduplicated across all projects, it may already exist. If
not, the temporary file is copied to the correct place, and will be
used by all future LFS objects with the same OID.

Workhorse uses the Content-Type of the request to decide to follow this
routine, as the URLs are ambiguous. If the Content-Type is anything but
"application/octet-stream", the request is proxied directly to rails,
on the assumption that this is a normal file edit request. If it's an
actual LFS request with a different content-type, however, it is routed
to the Rails `upload_finalize` action, which treats it as an LFS upload
just as it would a workhorse-modified request.

The outcome is that users can upload LFS objects that don't match the
declared size or OID. They can also create links to LFS objects they
don't really own, allowing them to read the contents of files if they
know just the size or OID.

We can close this hole by requiring requests to `upload_finalize` to be
sourced from Workhorse. The mechanism to do this already exists.

To support environment folders in the UI on the Environments List
page, the environments index route previously returned one environment
per folder, excluding those other than the latest deploy. However, the
environtments dropdown on the metrics dashboard requires that any
environment be selectable.

To accommodate both use cases, support an optional 'nested' parameter
in the index route to return either a flat, complete response or a
nested response based on the use case in question. The new default
response structure is the flat response.

We introduced the feature flag `error_tracking` to test the Sentry MVC
safely.

After the successful test, we remove it again.