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

.secret stores the secret token used for both encrypting login cookies
and for encrypting stored OTP secrets. We can't rotate this, because
that would invalidate all existing OTP secrets.

If the secret token is present in the .secret file or an environment
variable, save it as otp_key_base in secrets.yml. Now .secret can be
rotated without invalidating OTP secrets.

If the secret token isn't present (initial setup), then just generate a
separate otp_key_base and save in secrets.yml.

Update the docs to reflect that secrets.yml needs to be retained past
upgrades, but .secret doesn't.

Refactor user authorization check for a single project to avoid querying all user projects

See merge request !5102

Added the ability to block sign ups using a domain blacklist.

As part of this MR, I restructured the Application Settings form to separate **Sign up** related settings from **Sign in** related settings and make everything cleaner and easier to read.

Fixes #19749 

Related to #5573

See merge request !5259

Currently, even when searching for all authorized issues of *one* project, we run the
`Users#authorized_projects` query (which can be rather slow). This update checks if
we are handling issues of just one project and does the authorization check locally.
It does have the downside of basically repeating the logic of `Users#authorized_projects`
on `Project#authorized_for_user`.

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