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`