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.

1. Improve error handling while creating protected branches.

2. Modify coffeescript code so that the "Developers can *" checkboxes
   send a '1' or '0' even when using AJAX. This lets us keep the backend
   code simpler.

3. Use services for both creating and updating protected branches.
   Destruction is taken care of with `dependent: :destroy`

- And hook up their associations.

1. Remove the `developers_can_push` and `developers_can_merge` boolean
   columns.

2. Add two new tables, `protected_branches_push_access`, and
   `protected_branches_merge_access`. Each row of these 'access' tables is
   linked to a protected branch, and uses a `access_level` column to
   figure out settings for the protected branch.

3. The `access_level` column is intended to be used with rails' `enum`,
   with `:masters` at index 0 and `:developers` at index 1.

4. Doing it this way has a few advantages:

   - Cleaner path to planned EE features where a protected branch is
     accessible only by certain users or groups.

   - Rails' `enum` doesn't allow a declaration like this due to the
     duplicates. This approach doesn't have this problem.

       enum can_be_pushed_by: [:masters, :developers]
       enum can_be_merged_by: [:masters, :developers]

Change `LdapGroupSync` worker to use new Group Sync classes

This was missed before - somehow 😞 The old `group_sync` class was left and the worker still pointed to it. Unfortunately, this means that 8.11 shipped with the new modular code but it is not in use. In the interest of not introducing a possible regression, we may as well wait until 8.11. 



See merge request !601

Fix regression in Git Annex permission check

The `changes` in git-annex-shell mean a different thing than git-receive-pack. Revert to the previous code and use a simple check whether Git Annex is enabled.

See merge request !599

CE upstream



See merge request !600

Added update guide for 8.11

## What does this MR do?

I need to add notes about Elastic on EE side. To not create ugly conflicts in the future and to not duplicate work I created it here first.

I followed this guide https://gitlab.com/gitlab-org/release-tools/blob/master/doc/release-candidates.md#gitlab-ce

See merge request !5545

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

The `changes` in git-annex-shell mean a different thing than
git-receive-pack. Revert to the previous code and use a simple check
whether Git Annex is enabled.

Replace reject_blocked with reject_blocked! in skipped callbacks.

`reject_blocked!` was introduced in c9def945, I can't find any references to `reject_blocked` ever existing.

See merge request !5532

In Rails 4.2 and below, skipping callbacks (skip_before_action, skip_after_action, etc.) that use methods which do not exist will not throw any errors.

On the other hand, Rails 5 does. See https://github.com/rails/rails/pull/19029

After testing with Rails 5 I noticed there are some methods that don't actually exist (because they were renamed, usually), this fixes a few instances of those.

reject_blocked! was introduced in c9def945, I can't find any references to reject_blocked ever existing.

Submit new issues created via the WebUI or API to Akismet for spam check on public projects.

## What does this MR do?

Submit new issues created via the WebUI by non project members to Akismet for spam check.

## Why was this MR needed?

Support for Akismet was added only to the API with !2266. This MR builds on that functionality to also check issues submitted via the WebUI for spam.

## What are the relevant issue numbers?

Related to:

- #5573 
- #5932 
- gitlab-com/infrastructure#14
- gitlab-com/support#61
- !2266

cc @stanhu @MrChrisW 

See merge request !5333

Update attr_encrypted from 3.0.1 to 3.0.2

This removes methods that were deprecated by Rails 5 so we won't have as many deprecation warnings when we update to Rails 5. Working toward #14286.

Changelog: https://github.com/attr-encrypted/attr_encrypted/blob/master/CHANGELOG.md#302

See merge request !5438

Update rack-oauth2 from 1.2.1 to 1.2.3.

Removes methods deprecated in Rails 5. Working toward #14286.

Changelog: https://github.com/nov/rack-oauth2/compare/v1.2.1...v1.2.3

See merge request !5439