The gitlab:check rake task checks ES version according to requirements

See merge request !824

Improve Geo documentation for 8.13

This merge-request was initiated after feedback from costumers about our documentation.

It's a bunch of small fixes to add extra troubleshooting and improve the understanding of the required steps.

# Documentation changes/added:

- [x] Add "Host key verification" troubleshooting doc for Geo
- [x] Update rsync instructions to preserve repository user/group ownership
- [x] Communicate better the setup steps and the correct order they must happen

cc @dewetblomerus @marin

See merge request !766

Add a trigger variable to docs trigger job

From https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7089

See merge request !819

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

Fix branch protection API

- EE-specific (spec) changes related to gitlab-org/gitlab-ce!6215.
- Related to gitlab-org/gitlab-ce#21513.

See merge request !718

Hides multiple board actions if user doesnt have permissions

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

See merge request !816

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

Fix for Elasticsearch::Transport::Transport::Errors::BadRequest: [400]

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/21036

See merge request !818

Extract/mutate `params` in the `execute` method of the API services,
rather than in `initialize`.

- Pass `developers_and_merge` and `developers_can_push` in `params`
  instead of using keyword arguments.

- Refactor a slightly complex boolean check to a simple `nil?` check.

1. Add an EE-specific spec.

2. The code deleting redundant access levels is different for EE, since
   EE protected branches can have 0 or more access levels, while CE
   protected branches can have a single access level.

Existing access levels (apart from 'developer' access levels) should not
be removed while using the branch protection API.

1. Don't have any EE-only code in CE. Ok to have CE-only code in EE.

2. Use `case` instead of `if/elsif`

1. Previously, we were not removing existing access levels before
   creating new ones. This is not a problem for EE, but _is_ for CE,
   since we restrict the number of access levels in CE to 1.

2. The correct approach is:

    CE -> delete all access levels before updating a protected branch
    EE -> delete developer access levels if "developers_can_{merge,push}" is switched off

3. The dispatch is performed by checking if a "length: 1" validation is
   present on the access levels or not.

4. Another source of problems was that we didn't put multiple queries in
   a transaction. If the `destroy_all` passes, but the `update` fails,
   we should have a rollback.

5. Modifying the API to provide users direct access to CRUD access
   levels will make things a lot simpler.

6. Create `create/update` services separately for this API, which
   perform the necessary data translation, before calling the regular
   `create/update` services. The translation code was getting too large
   for the API endpoint itself, so this move makes sense.

Fix lint-doc error

See this build error -> https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/817

I didn't add a CHANGELOG entry because I don't think is needed but just let me know if you think we should add it

See merge request !817

Update license API docs [ci skip]

Docs for gitlab-org/gitlab-ee!400

I forgot the docs in the above merge request so here they are. This adds the new `POST /license` endpoint. 

See merge request !413

Re-organize queues for EE

See merge request !815

This builds on
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7006 and adjusts
various parts to take care of EE specific workers.

Dumping too many jobs in the same queue (e.g. the "default" queue) is a
dangerous setup. Jobs that take a long time to process can effectively
block any other work from being performed given there are enough of
these jobs.

Furthermore it becomes harder to monitor the jobs as a single queue
could contain jobs for different workers. In such a setup the only
reliable way of getting counts per job is to iterate over all jobs in a
queue, which is a rather time consuming process.

By using separate queues for various workers we have better control over
throughput, we can add weight to queues, and we can monitor queues
better. Some workers still use the same queue whenever their work is
related. For example, the various CI pipeline workers use the same
"pipeline" queue.

This commit includes a Rails migration that moves Sidekiq jobs from the
old queues to the new ones. This migration also takes care of doing the
inverse if ever needed. This does require downtime as otherwise new jobs
could be scheduled in the old queues after this migration completes.

This commit also includes an RSpec test that blacklists the use of the
"default" queue and ensures cron workers use the "cronjob" queue.

Fixes gitlab-org/gitlab-ce#23370

Port gitlab-org/gitlab-ce!7033 to EE

See merge request !814

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

Fix a search for non-default branches when ES is enabled

The issue was introduced in 8.12

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

See merge request !811

Merge branch 'ce-22457-reset-filters-button-should-be-invisible-when-no-filters-are-active-ee' into 'master'

`Reset filters` link should only be visible when filters are active

**EE version of gitlab-org/gitlab-ce!6497.**

## What does this MR do?

> Adds `issuable_filters_present` helper method to check for any filters before rendering the reset link.

## Why was this MR needed?

> `Reset filters` link is always visible.

See merge request !785

[ci skip]

[ci skip]

Update merge_requests.md.

Error in 'Approve merge request'  section in API documentation

## What does this MR do?

Just fix an error in API Documentation in 'Approve Merge Request' section. 

Url in documentation : 
`POST /projects/:id/merge_requests/:merge_request_id/approvals`

Should be : 
`POST /projects/:id/merge_requests/:merge_request_id/approve`

(Verified on gitlab 8.12.7-ee 4051516)

See merge request !809

Cache the last usage data to avoid unicorn timeouts

On GitLab.com, the usage data cache was never populated because it takes longer than 60 seconds to generate.

This MR also improves usage data performance. The Event default_scope was causing the query to use the wrong index, causing the query to scan through all rows unnecessarily.

Closes #1044

See merge request !779

Added tests