We had a number of team members struggle to find invited members of a
group. Searching for the e-mail address did not work because search only
works with members with user accounts.

This commit changes two things:

1. Breaks out the invited members into a separate table.
2. Adds search capability for the invited members.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/61948

When using the members/all api the same user was returned multiple times
when he was a member of the project/group and also of one of the
ancestor groups.
Now the member is returned only once giving priority to the membership
on the project and maintaining the same behaviour of the members UI.

Suppose you have this configuration:

1. Subgroup `hello/world`
2. Subgroup `hello/mergers`.
3. Project `hello/world/my-project` has invited group `hello/world` to
access protected branches.
4. The rule allows the group to merge but no one can push.
5. User `newuser` has Owner access to the parent group `hello`.

Previously, there was no way for the user `newuser` to be added to the
`hello/mergers` group since the validation only allowed a user to be
added at a higher access level.

Since membership in a subgroup confers certain access rights, such as
being able to merge or push code to protected branches, we have to
loosen the validation and allow someone to be added at an equal level
granted by the parent group.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/11323

Renamed EmailValidator to DeviseEmailValidator to avoid 'email:' naming collision with ActiveModel::Validations::EmailValidator in 'validates' statement.
Make use of the options attribute of the parent class ActiveModel::EachValidator.
Add more options: regex.

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

Signed-off-by: NRémy Coutable <remy@rymai.me>

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

Resolve "Can add an existing group member into a group project with new permissions but permissions are not overridden"

GitLab EE extends Member#add_user by adding some LDAP specific flags.
Prior to these changes, the only way this could be done was by modifying
Member#add_user in place. This could lead to merge conflicts whenever a
developer wants to change this method.

To resolve this issue, the logic that EE extends has been moved into a
separate method with the appropriate arguments. This allows EE to extend
the logic by prepending the method using an EE specific module.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Partially addresses #47424.

* Show 2fa badge on a group members page
* Make group members page UI consistent with project members page
* Fix ambiguous sql in User.with/without_two_factor methods
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: NRémy Coutable <remy@rymai.me>

Move it to Members::ApproveAccessRequestService.

Also, note that there was a double audit event log for access request
destruction.
Signed-off-by: NRémy Coutable <remy@rymai.me>

- Create MemberPresenter alongside with GroupMemberPresenter and ProjectMemberPresenter
- Make Member model Presentable
- Move action_member_permission from MembersHelper into the MemberPresenter
- Added rspec using double, separate specs for GroupMemberPresenter and ProjectMemberPresenter

Fixes #28004.
Signed-off-by: NRémy Coutable <remy@rymai.me>

The following optimizations were performed:

- Add new association to GroupMember and ProjectMember

  This new association will allow us to check if a user is a member of a
  Project or Group through a single query instead of two.

- Optimize retrieving of Members when adding multiple Users

since this is for user invites and the like.

One should really use a separate table instead of using polymorphic
associations.

See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11168 for
more information.

Previously, only group masters could do this. However, project reporters can
manage project labels, so there doesn't seem to be any need to restrict group
labels further.

Also, save a query or two by getting a single GroupMember object to find out if
the user is a master or not.

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

This reverts commit e00fb2bdc2090e9cabeb1eb35a2672a882cc96e9.

# Conflicts:
#	.rubocop.yml
#	.rubocop_todo.yml
#	lib/gitlab/ci/config/entry/global.rb
#	lib/gitlab/ci/config/entry/jobs.rb
#	spec/lib/gitlab/ci/config/entry/factory_spec.rb
#	spec/lib/gitlab/ci/config/entry/global_spec.rb
#	spec/lib/gitlab/ci/config/entry/job_spec.rb
#	spec/lib/gitlab/ci/status/build/factory_spec.rb
#	spec/lib/gitlab/incoming_email_spec.rb

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.