The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.

To fix this:

1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
   `Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
   like that in several places.
3. Change the initializers to use that new form.

`allowed_key_types` is removed and the `minimum_<type>_bits` fields are
renamed to `<tech>_key_restriction`. A special sentinel value (`-1`) signifies
that the key type is disabled.

This also feeds through to the UI - checkboxes per key type are out, inline
selection of "forbidden" and "allowed" (i.e., no restrictions) are in.

As with the previous model, unknown key types are disallowed, even if the
underlying ssh daemon happens to support them. The defaults have also been
changed from the lowest known bit size to "no restriction". So if someone
does happen to have a 768-bit RSA key, it will continue to work on upgrade, at
least until the administrator restricts them.

This is an amalgamation of:

* Cory Hinshaw: Initial implementation !5552
* Rémy Coutable: Updates !9350
* Nick Thomas: Resolve conflicts and add ED25519 support !13712

When sign-in is disabled:
 - skip password expiration checks
 - prevent password reset requests
 - don’t show Password tab in User Settings
 - don’t allow login with username/password for Git over HTTP requests
 - render 404 on requests to Profiles::PasswordsController

Additionally some missing translations were added

This will be necessary when adding gitaly settings. This version
doesn't make any functional changes, but allows us to include this
breaking change in 9.0 and add the needed extra settings in the future
with backwards compatibility

Review changes

This commit alters views for the following models to use the markdown cache if
present:

* AbuseReport
* Appearance
* ApplicationSetting
* BroadcastMessage
* Group
* Issue
* Label
* MergeRequest
* Milestone
* Project

At the same time, calls to `escape_once` have been moved into the `single_line`
Banzai pipeline, so they can't be missed out by accident and the work is done
at save, rather than render, time.

Koding: #index: landing page for Koding integration

If enabled it will provide a link to open remote Koding instance url
for now we are also providing the sneak preview video for how
integration works in detail.

Repository: check whether .koding.yml file exists on repository

Projects: landing page: show Run in IDE (Koding) button if repo has stack file

Projects: MR: show Run in IDE Koding button if repo has stack file on active branch

ProjectHelpers: add_koding_stack: stack generator for provided project

With this helper we will auto-generate the required stack template
for a given project. For the feature we can request this base template
from the running Koding instance on integration.

Currently this will provide users to create a t2.nano instance on aws
and it'll automatically configures the instance for basic requirements.

Projects: empty state and landing page provide shortcuts to create stack

projects_helper: use branch on checkout and provide an entry point

This ${var.koding_queryString_branch} will be replaced with the branch
provided in query string which will allow us to use same stack template
for different branches of the same repository.

ref: https://github.com/koding/koding/pull/8597/commits/b8c0e43c4c24bf132670aa8a3cfb0d634acfd09b

projects_helper: provide sha info in query string to use existing vms

With this change we'll be able to query existing vms on Koding side
based on the commit id that they've created.

ref: https://github.com/koding/koding/pull/8597/commits/1d630fadf31963fa6ccd3bed92e526761a30a343

Integration: Docs: Koding documentation added

Disable /koding route if integration is disabled

Use application settings to enable Koding

Projects_helper: better indentation with strip_heredoc usage

Projects_helper: return koding_url as is if there is no project provided

current_settings: set koding_enabled: false by default

Koding_Controller: to render not_found once integration is disabled

Dashboard_specs: update spec for Koding enabled case

Projects_Helper: make repo dynamic

ref: https://github.com/koding/koding/pull/8597/commits/4d615242f45aaea4c4986be84ecc612b0bb1514c

Updated documentation to have right format

Add a new application setting, after_sign_up_text. This is text to be
rendered as Markdown and shown on the 'almost there' page after a user
signs up, but before they've confirmed their account.

Tweak the styles for that page so that centered lists look reasonable.

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

This reverts commit 075ace5686c63d40f7e9fa02bf37e1bd3168f7e7.

This reverts commit 78a832d0fd7ff445c707809134dbb2a42d2a9e03.

Show help only for the enabled OAuth Providers on oauth-providers-help block

aria: { describedby: help_block_id } instead of 'aria-describedby' => help_block_id

provider and not p

a more simple approach to the OmniAuth helper links for oauth-providers-help

On Application Settings Page let the user select the enabled OAuth Sign in sources instead of the disabled ones

I’ve removed everything related to the feature based on this commit:
ce08f919f34fd8849834365

Resolves #10857.