This change helps system administrators who want to replicate
GitLab backup files without needing root permissions.

Now we can simply loop through all themes, among other things.

This also removes the `dark_theme` / `light_theme` classes and the
`theme_type` helper, since they weren't used anywhere.

delay is in seconds
more legible code in session_store
Added `GitLab restart required` help block to session_expire_delay

settings

Until now, a user needed to first sign in with his LDAP identity and then manually
link his/her account with an omniauth identity from their profile.
Only when this is done can the user authenticate with the omniauth provider and at
the same time benefit from the LDAP integration (HTTPS authentication with LDAP
username/password and in EE: LDAP groups, SSH keys etc.).
This feature automates the process by looking up a corresponding LDAP person when a
user connects with omniauth for the first time and then automatically linking the LDAP
and omniauth identities (of course, like the existing allow_single_sign_on setting,
this is meant to be used with trusted omniauth providers).
The result is identical to a manual account link.

Add config initializers for other omniauth settings.

Add an option to automatically sign-in with an Omniauth provider without showing the GitLab sign-in page

This is useful when integrating with existing SSO environments and we want to use a single Omniauth provider for
all user authentication.

This feature was requested long ago:

http://feedback.gitlab.com/forums/176466-general/suggestions/4118466-ability-to-register-only-from-ceratain-domains

This MR is based off !253 but changed to use application settings and use wildcard strings
to give more flexibility in pattern matching. Regexps seemed overkill and easy to get wrong.

Only restrict e-mail addresses upon creation

By imposing this rule we avoid having to demand that 'ldapmain' exists
in the settings initializer.

Closes #1305

Fix bug where error messages from Dropzone would not be displayed on the issues page

Closes #1258

successful Git over HTTP authentication.

Add logging when a ban goes into effect for debugging.

Issue #1171

for his work and help)

On some misconfigured GitLab servers, if you look in production.log it looks
like all requests come from 127.0.0.1. To avoid unwanted banning we
white-list 127.0.0.1 with this commit.