1. `GitPushService` was still using `{merge,push}_access_level_attributes` instead
   of `{merge,push}_access_levels_attributes`.

2. The branches API creates access levels regardless of the state of the
   `developers_can_{push,merge}` parameters. This is in line with the UI,
   where Master access is the default for a new protected branch.

3. Use `after(:build)` to create access levels in the
   `protected_branches` factory, so that `factories_spec` passes. It
   only builds records, so we need to create access levels on `build` as
   well.

!581 has a lot of changes that would cause merge conflicts if not
properly backported to CE. This commit/MR serves as a better
foundation for gitlab-org/gitlab-ee!581.

= Changes =

1. Move from `has_one {merge,push}_access_level` to `has_many`, with the
   `length` of the association limited to `1`. This is _effectively_ a
   `has_one` association, but should cause less conflicts with EE, which
   is set to `has_many`. This has a number of related changes in the
   views, specs, and factories.

2. Make `gon` variable loading more consistent (with EE!581) in the
   `ProtectedBranchesController`. Also use `::` to prefix the
   `ProtectedBranches` services, because this is required in EE.

3. Extract a `ProtectedBranchAccess` concern from the two access level
   models. This concern only has a single `humanize` method here, but
   will have more methods in EE.

4. Add `form_errors` to the protected branches creation form. This is
   not strictly required for EE compatibility, but was an oversight
   nonetheless.

Submit to Akismet Part 1 (Issues)

Related to #5932 #5573 gitlab-com/infrastructure#14

See merge request !5538

- Refactored SpamCheckService into SpamService

- Added controller actions as reusable concerns
- Added controller tests

- Removed unnecessary column from `SpamLog`
- Moved creation of SpamLogs out of its own service and into SpamCheckService
- Simplified code in SpamCheckService.
- Moved move spam related code into Spammable concern