Hide SSH repository mirroring

## What does this MR do?
Removes reference to `ssh://` URLs from the repository mirror settings page

## Are there points in the code the reviewer needs to double check?

- [ ] Is the screenshot now used in the documentation an appropriate resolution?
- [ ] Do the remaining screenshots need re-doing to match?

Repository mirroring is also referenced from the 'Import project by URL' functionality, where much of the text of `_instructions.html.haml` is duplicated in a separate partial. It doesn't mention `ssh://`, though.

## Why was this MR needed?

Mirroring repositories over SSH needs more work before it's generally useful.

Currently, these URLs are interpreted with the implicit context of the SSH client configuration for the GitLab installation's `git` user, particularly `known_hosts` and any SSH private keys it has access to. Unless the user manually alters these details  - especially `known_hosts` - then `ssh://` URLs just don't work. 

We don't wish to support and document manual SSH configuration management, and the naive approach (a single `id_rsa` file used when mirroring all repositories) is insecure - especially for GitLab.com or similar deployments.

Future MRs will re-add documentation for `ssh://` URLs for both password and public-key authentication once `known_hosts` and unique SSH keys for repository mirroring are handled automatically.

Disabling support for `ssh://` URLs entirely would break existing customer setups.

## What are the relevant issue numbers?

#98 #621

## Screenshots (if relevant)

![Screen_Shot_2016-08-02_at_10.58.23](/uploads/940bce89b6e8cc109f5df766cd287c7d/Screen_Shot_2016-08-02_at_10.58.23.png)

See merge request !608

Use a full-width, HiDPI screenshot of repository mirroring to more closely match existing screenshots

Move markdown doc to the right location



See merge request !612

[ci skip]

Document wiki linking behavior

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

See merge request !609

ES common index

This will allow as to use parent/child relationship in ES. Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/375

- [x] Fix settings overlapping 
- [x] Specs
- [x] Test everything
- [x] Change rake tasks
- [x] Change index settings for all models
- [x] Update the install doc
- [x] Update the update doc (I created https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5545)
- [x] Prepare text for release blog post


Proposed addition to releasepost:

We totally changed the structure of Elasticsearch  index this is why we need to remove whole index and build new one. To be able to use parent/child relationship in ES we decided to move everything in a single index. This solution has some drawback  - if we decide to change the type of some existing field in ES we will need to rebuild whole index for every entity. So it makes it harder to support but we expect to have more performance advantages with parent/child relationships. 

**Migration**

Remove old indexes

```
curl -XDELETE 'http://localhost:9200/_all/'
```

Build new indexes as described in [Elasticsearch integration](../integration/elasticsearch.md#add-gitlabs-data-to-the-elasticsearch-index)



See merge request !598

Add migration guide for 8.11

[ci skip]

See merge request !606

[ci skip]

Fix of `Commit search breaks for some URLs on gitlab-ce project`

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/835

See merge request !605

Rubocop - enable cops access modifiers

This is sync with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5014

See merge request !603

* master: (3075 commits)
  Fix rubocop spec.
  Implement final review comments from @rymai.
  Use `Gitlab::Access` to protected branch access levels.
  Fix `git_push_service_spec`
  Authorize user before creating/updating a protected branch.
  Have the `branches` API work with the new protected branches data model.
  Implement review comments from @axil.
  Remove duplicate specs from `git_access_spec`
  Implement review comments from @dbalexandre.
  Favor labels like `Allowed to push` over `Allowed To Push`.
  Add changelog entry.
  Admins count as masters too.
  Make specs compatible with PhantomJS versions < 2.
  Humanize protected branches' access levels at one location.
  Fix all specs related to changes in !5081.
  Fix default branch protection.
  Update protected branches spec to work with the `select`s.
  Allow setting "Allowed To Push/Merge" while creating a protected branch.
  Enforce "No One Can Push" during git operations.
  Add "No One Can Push" to the protected branches UI.
  ...

Conflicts:
	app/services/system_note_service.rb

Allow creating protected branches that can't be pushed to

- Mirror of this CE MR: gitlab-org/gitlab-ce!5081
- Having an EE MR for this feature should avoid merge conflicts later


See merge request !569

1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`

2. Use `can?(user, ...)` instead of `user.can?(...)`

3. Add `DOWNTIME` notes to all migrations added in !5081.

4. Add an explicit `down` method for migrations removing the
   `developers_can_push` and `developers_can_merge` columns, ensuring that
   the columns created (on rollback) have the appropriate defaults.

5. Remove duplicate CHANGELOG entries.

6. Blank lines after guard clauses.

1. It makes sense to reuse these constants since we had them duplicated
   in the previous enum implementation. This also simplifies our
   `check_access` implementation, because we can use
   `project.team.max_member_access` directly.

2. Use `accepts_nested_attributes_for` to create push/merge access
   levels. This was a bit fiddly to set up, but this simplifies our code
   by quite a large amount. We can even get rid of
   `ProtectedBranches::BaseService`.

3. Move API handling back into the API (previously in
   `ProtectedBranches::BaseService#translate_api_params`.

4. The protected branch services now return a `ProtectedBranch` rather
   than `true/false`.

5. Run `load_protected_branches` on-demand in the `create` action, to
   prevent it being called unneccessarily.

6. "Masters" is pre-selected as the default option for "Allowed to Push"
   and "Allowed to Merge".

7. These changes were based on a review from @rymai in !5081.

1. Caused by incorrect test setup. The user wasn't added to the project,
   so protected branch creation failed authorization.

2. Change setup for a different test (`Event.last` to
   `Event.find_by_action`) because our `project.team << ...` addition
   was causing a conflict.

1. This is a third line of defence (first in the view, second in the
   controller).

2. Duplicate the `API::Helpers.to_boolean` method in `BaseService`. The
   other alternative is to `include API::Helpers`, but this brings with it
   a number of other methods that might cause conflicts.

3. Return a 403 if authorization fails.

1. The new data model moves from `developers_can_{push,merge}` to
   `allowed_to_{push,merge}`.

2. The API interface has not been changed. It still accepts
   `developers_can_push` and `developers_can_merge` as options. These
   attributes are inferred from the new data model.

3. Modify the protected branch create/update services to translate from
   the API interface to our current data model.

1. Align "Allowed to Merge" and "Allowed to Push" dropdowns.

2. Don't display a flash every time a protected branch is updated.
   Previously, we were using this so the test has something to hook onto
   before the assertion. Now we're using `wait_for_ajax` instead.

- Likely introduced during an improper conflict resolution.

1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
   `max_member_access`, which is a lot nicer.

2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
   in migrations that don't need this module. Also remove comments where
   not necessary.

3. Remove duplicate entry in CHANGELOG.

4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.

5. Split the `set_access_levels!` method in two - one each for `merge` and
   `push` access levels.

- Based on feedback from @axil
- http://docs.gitlab.com/ce/development/ui_guide.html#buttons

1. In the context of protected branches.

2. Test this behaviour.

1. These versions of PhantomJS don't support `PATCH` requests, so we use
   a `POST` with `_method` set to `PATCH`.

1. The model now contains this humanization data, which is the once
   source of truth.

2. Previously, this was being listed out in the dropdown component as well.

1. Remove `Project#developers_can_push_to_protected_branch?` since it
   isn't used anymore.

2. Remove `Project#developers_can_merge_to_protected_branch?` since it
   isn't used anymore.

1. So it works with the new data model for protected branch access levels.

1. Get the existing spec passing.

2. Add specs for all the access control options, both while creating and
   updating protected branches.

3. Show a flash notice when updating protected branches, primarily so
   the spec knows when the update is done.

1. Reuse the same dropdown component that we used for updating these
   settings (`ProtectedBranchesAccessSelect`). Have it accept options
   for the parent container (so we can control the elements it sees) and
   whether or not to save changes via AJAX (we need this for update, but
   not create).

2. Change the "Developers" option to "Developers + Masters", which is
   clearer.

3. Remove `developers_can_push` and `developers_can_merge` from the
   model, since they're not needed anymore.

1. The crux of this change is in `UserAccess`, which looks through all
   the access levels, asking each if the user has access to push/merge
   for the current project.

2. Update the `protected_branches` factory to create access levels as
   necessary.

3. Fix and augment `user_access` and `git_access` specs.

1. Move to dropdowns instead of checkboxes. One each for "Allowed to
   Push" and "Allowed to Merge"

2. Refactor the `ProtectedBranches` coffeescript class into
   `ProtectedBranchesAccessSelect`.

3. Modify the backend to accept the new parameters.