Looking at the SQL log, we see useless queries such as:

```
D, [2017-03-22T03:25:00.726710 #2629] DEBUG -- :    (235.9ms)  SELECT MAX("project_authorizations"."access_level") AS maximum_access_level, "project_authorizations"."user_id" AS project_authorizations_user_id FROM "project_authorizations" WHERE "project_authorizations"."project_id" = 13083 AND 1=0 GROUP BY "project_authorizations"."user_id"  [["project_id", 13083]]
```

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.

Closes #23938

This also updates _some_ specs to use these new methods, just to serve
as an example for others going forward, but by no means is this
exhaustive.

Original implementations at !5992 and !6012.

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

`ProjectTeam#find_member` doesn't take group links into account. It was
used in two places:

1. An admin view - it can stay here.
2. `ProjectTeam#member?`, which is often used to decide if a user has
   access to view something.

This second part broke confidential issues viewing. `IssuesFinder` ends
up delegating to `Project#authorized_for_user?`, which does consider
group links, so users with access to the project via a group link could
see confidential issues on the index page. However, `IssuesPolicy` used
`ProjectTeam#member?`, so the same user couldn't view the issue when
going to it directly.

Changes include:

- Ensure Member.add_user is not called directly when not necessary
- New GroupMember.add_users_to_group to have the same abstraction level as for Project
- Refactor Member.add_user to take a source instead of an array of members
- Fix Rubocop offenses
- Always use Project#add_user instead of project.team.add_user
- Factorize users addition as members in Member.add_users_to_source
- Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects
- Destroy any requester before adding them as a member
- Improve the way we handle access requesters in Member.add_user
  Instead of removing the requester and creating a new member,
  we now simply accepts their access request. This way, they will
  receive a "access request granted" email.
- Fix error that was previously silently ignored
- Stop raising when access level is invalid in Member, let Rails validation do their work

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

We were calling `.where` and `.send` on the relation, but never doing
anything with the return value, resulting in proper access-level
filtering never being of any consequence.

Fixed spacing with buttons
Disables group form when user doesnt have correct permissions

We never add things `into` projects, we just add them `to` projects. So how about we rename this to `add_users_to_project`.

Rename `projects_ids` to `project_ids` by following the convention of rails.

1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
   `max_member_access`, which is a lot nicer.

2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
   in migrations that don't need this module. Also remove comments where
   not necessary.

3. Remove duplicate entry in CHANGELOG.

4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.

5. Split the `set_access_levels!` method in two - one each for `merge` and
   `push` access levels.

1. In the context of protected branches.

2. Test this behaviour.

NotesHelper#note_editable? and ProjectTeam#human_max_access currently
take about 16% of the load time of an issue page. This MR preloads
the maximum access level of users for all notes in issues and merge
requests with several queries instead of one per user and caches
the result in RequestStore.

And create new Project#requesters, Group#requesters scopes.

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

The previous implementation would load the entire team member list and their
respective attributes. Now we only search for the user's specific
access level.

In gitlab-com/operations#42, this reduces the overall overhead of rendering
the issue from 28% to 20%.

First step of optimizing #19273

This reverts commit 13e37a3e.

+ Move 'Edit Project/Group' out of membership-related partial
+ Show the access request buttons only to logged-in users
+ Put the request access buttons out of in a more visible button
+ Improve the copy in the #remove_member_message helper

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

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

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

By comparing objects in Ruby we can greatly improve the performance of
this method. In the worst case (should no data be eager loaded) this
will run the same amount of queries as before, in the best case (when
data _is_ eager loadeD) it requires no queries at all.

The added benchmark used to produce around 273 iterations per second.
With this commit this has been increased to almost 40 000 iterations per
second: a speedup of roughly 145 times.

Combined with eager loading Note associations this results in about 30
queries less when viewing a single issue, this in turn cuts down the
loading time by 30-40%.