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

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5620#note_13671791

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5620#note_13540099

Prior, when providing a `min_access_level` parameter to this method, we
called `Gitlab::Access.values` instead of `all_values`, mistakenly
omitting the `OWNER` level.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19878

Refactor and rename `restricted_signup_domains` to `domain_whitelist` to better conform to its behavior and newly introduced behavior.

As requested by the issue #14508 this adds an option in the application
settings to set newly registered users by default as external. The
default setting is set to false to stay backward compatible.

The issue was with the `User#groups` and `User#projects` associations
which goes through the `User#group_members` and `User#project_members`.

Initially I chose to use a secure approach by storing the requester's
user ID in `Member#created_by_id` instead of `Member#user_id` because I
was aware that there was a security risk since I didn't know the
codebase well enough.

Then during the review, we decided to change that and directly store the
requester's user ID into `Member#user_id` (for the sake of simplifying
the code I believe), meaning that every `group_members` / `project_members`
association would include the requesters by default...

My bad for not checking that all the `group_members` / `project_members`
associations and the ones that go through them (e.g. `Group#users` and
`Project#users`) were made safe with the `where(requested_at: nil)` /
`where(members: { requested_at: nil })` scopes.

Now they are all secure.
Signed-off-by: NRémy Coutable <remy@rymai.me>

Feedback from:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12301563

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12274602

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12217415

Feedback from:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12194552

Feedback from:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12194489

Feedback from:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12194471

- To hold registrations from U2F devices, and to authenticate them.
- Previously, `User#two_factor_enabled` was aliased to the
  `otp_required_for_login` column on `users`.
- This commit changes things a bit:
    - `User#two_factor_enabled` is not a method anymore
    - `User#two_factor_enabled?` checks both the
      `otp_required_for_login` column, as well as `U2fRegistration`s
    - Change all instances of `User#two_factor_enabled` to
      `User#two_factor_enabled?`
- Add the `u2f` gem, and implement registration/authentication at the
  model level.

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:

1. It assumes a user can always view all of their starred projects in
   perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
   can view. This is currently the case, but bugs happen.

Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.

In 8278b763 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.

Fixes: #17382

This reverts commit 01160fc0, reversing
changes made to 4bff9daf.

Also incorporates the review into this, mainly spec changes.

The user has the rights of a public user execpt it can never create a project,
 group, or team. Also it cant view internal projects.

Closes #13905

Prior, if the user enabled 2FA, then disabled it and came back some time
after the grace period expired, they would be forced to enable 2FA
immediately.