This can be done trough the API for the current user, or on the
profile page.

`perform_enqueued_jobs` is a Sidekiq method.
Using this method violates the Dependency inversion principle[0].

This commit replaces `perform_enqueued_jobs` with ActiveJob's abstract
method `perform_enqueued_jobs` in specs.

[0]: https://en.wikipedia.org/wiki/Dependency_inversion_principle

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

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

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

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

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

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

- The `/users` and `/users/:id` APIs are now accessible without
  authentication (!12445), and so scopes are not relevant for these endpoints.

- Previously, we were testing our scope declaration against these two methods.
  This commit moves these tests to other `GET` user endpoints which still
  require authentication.

- Rather than using an explicit check to turn off authentication for the
  `/users` endpoint, simply call `authenticate_non_get!`.

- All `GET` endpoints we wish to restrict already call
  `authenticated_as_admin!`, and so remain inacessible to anonymous users.

- This _does_ open up the `/users/:id` endpoint to anonymous access. It contains
  the same access check that `/users` users, and so is safe for use here.

- More context: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12445#note_34031323

- Use `GlobalPolicy` to authorize the users that a non-authenticated user can
  fetch from `/api/v4/users`. We allow access if the `Gitlab::VisibilityLevel::PUBLIC`
  visibility level is not restricted.

- Further, as before, `/api/v4/users` is only accessible to unauthenticated users if
  the `username` parameter is passed.

- Turn off `authenticate!` for the `/api/v4/users` endpoint by matching on the actual
  route + method, rather than the description.

- Change the type of `current_user` check in `UsersFinder` to be more
  compatible with EE.

- Test `GET` endpoints to check that the scope is allowed.
- Test `POST` endpoints to check that the scope is disallowed.
- Test both `v3` and `v4` endpoints.

- Scope declarations of the form:

    allow_access_with_scope :read_user, if: -> (request) { request.get? }

  will only apply for `GET` requests

- Add a negative test to a `POST` endpoint in the `users` API to test this. Also
  test for this case in the `AccessTokenValidationService` unit tests.

- Declaring an endpoint's scopes in a `before` block has proved to be
  unreliable. For example, if we're accessing the `API::Users` endpoint - code
  in a `before` block in `API::API` wouldn't be able to see the scopes set in
  `API::Users` since the `API::API` `before` block runs first.

- This commit moves these declarations to the class level, since they don't need
  to change once set.

- The issue filtering frontend code needs access to this API for non-logged-in
  users + public projects. It uses the API to fetch information for a user by
  username.

- We don't authenticate this API anymore, but instead - if the `current_user` is
  not present:

  - Verify that the `username` parameter has been passed. This disallows an
    unauthenticated user from grabbing a list of all users on the instance. The
    `UsersFinder` class performs an exact match on the `username`, so we are
    guaranteed to get 0 or 1 users.
  - Verify that the resulting user (if any) is accessible to be viewed publicly
    by calling `can?(current_user, :read_user, user)`