[master] Resolve "Reflected XSS in OAuth Authorize window due to redirect_uri allowing arbitrary protocols"

See merge request gitlab/gitlabhq!2572

Since we only need the `can?` view helpers there, it's better to
include those in a separate controller.

If we inherit from `ApplicationController` we also need to deal with
authentication, that needs to be done in some, but not all doorkeeper controllers.

This will make sure the `ApplicantionController#can?` method is
available for views rendering menus based on the current user's abilities.

Closes #37789

Closes #20628 by re-enabling implicit grant in Doorkeeper config. OAuth2 documentation refactored. 

 - cleanup formating in haml
 - clarify time window is in seconds
 - cleanup straneous chunks in db/schema
 - rename count_uniqe_ips to update_and_return_ips_count
 - other

- Move the `Oauth2::AccessTokenValidationService` class to
  `AccessTokenValidationService`, since it is now being used for
  personal access token validation as well.

- Each API endpoint declares the scopes it accepts (if any). Currently,
  the top level API module declares the `api` scope, and the `Users` API
  module declares the `read_user` scope (for GET requests).

- Move the `find_user_by_private_token` from the API `Helpers` module to
  the `APIGuard` module, to avoid littering `Helpers` with more
  auth-related methods to support `find_user_by_private_token`

Added checks for 2FA to the API `/sessions` endpoint and the Resource Owner Password Credentials flow.

This reverts commit 13e37a3e.

Auth.find was a very generic name for a very specific method.
Auth.find_in_gitlab_or_ldap was inaccurate in GitLab EE where it also
looks in Kerberos.

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

See #17478

Closes #1612