Use just SQL to check is a user can admin_issue on a project

Tradeoff

- we duplicate how we check admin_issue in a SQL relation in the Ability class

Also, mutualize AccessRequests and Members endpoints for Group &
Project.
New API documentation for the AccessRequests endpoints.
Signed-off-by: NRémy Coutable <remy@rymai.me>

Instead of redirecting from the project service to the service and back to the model,
put all destruction code in the service. Also removes a possible source of failure
where run_after_commit may not destroy the project.

This is in preparation to address the DB load caused by the counting in
gitlab-com/infrastructure#303.

developer cannot push to protected branch when project is empty or he has not been granted permission to do so

squashed - fixed label and milestone association problems, updated specs and refactored reader class a bit

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.

Helping to diagnose #20178

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5347#note_13204564

Currently, even when searching for all authorized issues of *one* project, we run the
`Users#authorized_projects` query (which can be rather slow). This update checks if
we are handling issues of just one project and does the authorization check locally.
It does have the downside of basically repeating the logic of `Users#authorized_projects`
on `Project#authorized_for_user`.

This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME
subquery'

Oh well.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5347#note_13199055

So we no longer join anything, just find the latest pipeline
and load builds from there to avoid mixing builds.

Thanks Kamil for the help and tests.

also added a test for checking this.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5347#note_13173842

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5347#note_13173871

* This method previously iterated over all services in a project.  Now it
will directly query the ExternalWikiService for the project and filter
by active state.
* The presence of an external wiki is also cached
* When an external wiki is added or removed, the cached value is updated

This was extracted from !5142 and implementing part of #4255.
We split it from !5142 because we want to ship it in 8.10
while !5142 was not ready yet.

This reverts commit 530f5158.

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

preventing settings from being saved

This reverts commit 9ca633eb, reversing
changes made to fb229bbf.

- Cherry-picked from `mvestergaard:branch-protection-dev-merge`
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220

fixes a few issues to do with import_url not being saved correctly for imports. This should prevent the import_data to be created when it should not and output an error properly validating before creating it.

Some context:
http://doc.gitlab.com/ce/api/repository_files.html#get-file-from-repository
http://doc.gitlab.com/ce/api/repositories.html#list-repository-tree

Slack:
https://gitlab.slack.com/archives/questions/p1467890450002077

1. The `open_branches` method is used to provide a list of branches
   while creating a protected branch.

2. It makes sense to include branches which are matched by one or more
   wildcard protected branches, since the user might want to make exact
   protected branches from these as well.

3. This also provides a large performance improvement. On my machine, in
   a project with 5000 branches and 2000 protected branches, the
   `ProtectedBranches#index` page went from a 40 seconds load time to 4
   seconds (10x speedup).