1. EE access control specs are significantly different, so this is a way
   to reduce potential merge conflicts. EE and CE specs go in separate files.

1. Previously, we had a separate test for each and every possible role,
   and another test for access by user, each multiplied by the access
   types (merge and push), and further multiplied by the type of CRUD
   operation (create or update).

2. Since we allow selecting multiple access levels at once, it makes
   sense to collapse a lot of these tests. Now, in single test, we check
   access levels for all roles and 5 different users. Multiply that by
   4 (as mentioned above), and we only have 4 tests total (that still
   test everything the previous tests did).

3. Use a shared example to reduce potential conflicts in the future,
   since CE access control specs are significantly different.

1. This has been moved to the `#index` page.

1. For a user-based access level, don't validate `access_level`
2. For a role-based access level, don't look at `access_level` of user-based access levels

Add tests supporting this behavior.

1. A validation restricts a protected branch so it can only have a
   single access level for a given role or user.

2. More context:

    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14051822
    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14052756
    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14056066
    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14058676

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

1. We might need to update/delete access levels that were created in
   this `update` call without a page refresh.

2. The JS relies on the JSON response for the IDs of the newly created
   access level records.

- Using the `allow_destroy` option for `accepts_nested_attributes_for`

1. No need to change the spec for `UserAccess#can_push_to_branch?` for
   EE anymore.

2. Make the `dropdowns_helper` change additive to CE, so as to reduce
   the potential for merge conflicts.

- In 5b92c54319cd0e10f879a35bf6aab85a8e04e540, we destroyed all the
  default access levels for a factory-created protected branch.

- Inadvertently, we also destroyed all spec-created access levels,
  leading to a number of failures, which should now be fixed.

- As part of gitlab-org/gitlab-ce!5824, the `protected_branches` factory
  creates default `MASTER` access levels for merging and pushing.

- Some specs rely on the condition that no pre-existing access levels
  exist when a protected branch is created, and these specs were
  failing.

- Added a factory trait to remove the default access levels.

- Project needs to be loaded before `find_users` is called.

1. Check if a project is readable by the current user when fetching
   users for autocomplete.

2. Remove duplication relating to gon variables in
   `ProtectedBranchesController`

3. Remove unnecessary colons in view labels.

4. Remove an explicit `false` check in the `branches` API.

- Primarly whitespace and code style changes.

- Improve feature spec dealing with removing a user from a protected
  branch. Previously, we were only asserting on a "Deleted" flash
  notice. Now the assertion looks at the database to make sure that the
  right access level was removed.