- There's no real need to have this module _and_ `EE::User`

- This commit moves the contents of `EE::AuditorUser` to `EE::User`

Refactor the EE::User module

Changed ratio button label from Audit to Auditor, also
changed "Admin" label to "Access level"

Use partials and backport code where necessary.

There were failures related to cross-spec contamination of the `License` mocks.

1. The edit user page allows making a user an admin or an auditor. This creates
   a virtual attribute called `access_level` which can have `regular`, `admin`,
   or `auditor` as valid values.

2. The `access_level=` method was broken, which led to the page not accepting
   changes to a user's access level.

3. This commit fixes the issue and adds specs for `access_level=`

Mainly related to increasing compatibility with CE, and trying to avoid merge
conflicts.

1. Create an `EE::AuditorUser` module with auditor-specific methods. Mixed into
   the `User` model.

2. Create an `EE::User` module with EE-specific user methods. Mixed into the
   `User` model.

3. Don't block creation of regular users when the auditor addon is disabled (bug
   in original implementation).

Changed the access checkboxes to radio buttons as to only
allow one particular type of user active at all times.

The new user types are as follows:
* Regular
* Auditor
* Admin

1. The add-on is named `GitLab_Auditor_User`

2. An auditor user cannot be created if the addon is not present.

3. `auditor?` always returns `false` if the addon is not present.

1. `add_column_with_default` needs a `down` block

2. Add specs for the auditor user to `spec/features/security`. This directory
   contains a series of feature specs to test the access various user roles have
   to various project/admin pages, which is the perfect place to test auditor
   user access.

3. Other minor changes (views, typos)

1. Projects under the groups they belong to, or under their own personal
   namespace. They cannot create projects under groups they don't have explicit
   control over.

2. Since we're thinking of auditor users as "regular users with readonly access
   to everything they wouldn't normally see", it makes sense to let them do
   anything a regular user would do, including creating projects and groups.

The `ProjectPolicy` is meant to be declarative in nature, and it isn't
necessarily a good idea to remove all duplication here. That level of
indirection would _hurt_ readability, rather than improve it.

1. Extract an `admin_or_auditor?` method to clean up multiple uses of
  `user.admin? || user.auditor?`

2. Follow the four phase test rule.

3. Clean up the `project_policy_spec` by using %i for literal symbols

4. A number of other minor improvements.

Don't repeat declarations that are common between anonymous and auditor users.

All finders, policies and controllers that needed to be modified to include an
`auditor` check are tested here

In addition, allow an auditor read-only permissions within a project.

  Collect all the permissions that an auditor is supposed to have in the
  `auditor_access` method. This _could_ be automated by dynamically listing all
  permissions that start with `read_`, but this is cleaner / more readable,
  especially since it's confined to this one location.

An auditor user is intended to be user with read-only access to all projects and
groups. Access to the admin area and any project settings pages are disallowed

This commit lays the initial groundwork for this concept - adding an `auditor`
column to the `users` table, as well as a few supplements.

Port "V4 API: Remove deprecated MR and Issue endpoints and preserve V3 namespace"

See merge request !1166

Geo: send the new event type with the backfill function

Closes #1645

See merge request !1157

CE upstream

Closes gitlab-ce#27674

See merge request !1170

CE upstream

Closes #395

See merge request !1161

Add index to labels for `type` and project_id`

Closes #27676

See merge request !8978

Fixed typo in slash commands docs

Closes #27674

See merge request !8976

Fix "NameError: uninitialized constant Rack::Proxy" in production environment

See merge request !1168

When loading pages that display the number of open issues,
the backend runs a query such as:

```sql
SELECT "labels"."id" FROM "labels" WHERE "labels"."type" IN ('ProjectLabel') AND "labels"."project_id" = 1000
```

This results in an entire scan of the `labels` table. To optimize performance,
add the appropriate index to the table.

Closes #27676

Fix "NameError: uninitialized constant Rack::Proxy" in production environment

See merge request !8977