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

- `#find_users` depends on a project being loaded.

- Missed adding this in 2193ae22

- This is an optimization that was made in !581, and it needs to be
  backported to CE to avoid merge conflicts in the future.

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.

1. To improve EE compatibility.

!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.

- Refactored SpamCheckService into SpamService

- Added controller actions as reusable concerns
- Added controller tests

- Added `submitted_as_ham` to `SpamLog` to mark which logs have been submitted to Akismet.
- Added routes and controller action.

- 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

- Merged `AkismetSubmittable` into `Spammable`
- Clean up `SpamCheckService`
- Added tests for `Spammable`
- Added submit (ham or spam) options to `AkismetHelper`

- New concern `AkismetSubmittable` to allow issues and other `Spammable` models to be submitted to Akismet.
- New model `UserAgentDetail` to store information needed for Akismet.
- Services needed for their creation and tests.

This ensures that SVGs greater than 2 megabytes are not scrubbed and
rendered. This in turn prevents requests from timing out due to
reading/scrubbing large SVGs potentially taking a lot of time (and
memory). The use of 2 megabytes is completely arbitrary.

Fixes gitlab-org/gitlab-ce#1435

Closes #20828

Currently when a user performs an update of a file through the UI  and there
has already been a change committed to the file the previous commits will be
overwritten without a check to see if the file has been changed.

This commit uses the last commit sha at the time the user starts editing the
file and compares it with the current sha of the file being edited to ensure
they are the same before committing the file. If the shas do not match we
throw an exception preventing the commit from the commit from occurring.

Fixes #5857

We’re being kept up to date the counter data but we’re not using it.
The only thing which is not real if is the number of projects that the 
user read changes the number of todos can be stale for some time.

The counters will be sync just after the user receives a new todo or mark any as done