“Can create groups” and “Can create teams” had hardcoded defaults to
`true`. Sometimes it is desirable to prohibit these for newly created
users by default.

Conflicts:
	config/gitlab.yml.example
	config/initializers/1_settings.rb

This option allows to disable users from changing their username.

This is very usefull in environments using strong internal authentication methods like ldap, pam or shibboleth.

You can allow users to change theyr username in these environments, but then new users (users loging in first time) is blocked from gitlab is her username exists.

error is that ```enabled ||= true``` always evaluates to true.
Change all initialization of bool settings to use the same syntax:
```setting = true if setting.nil?```

The tasks gitlab:env:info mixes user and group, and presume as a group 'git'.
However, gitolite group name can be anything.

That patch add the git group name in the config,
and check gitolite.ssh_user group against git.group
(which defaults to 'git', as before this patch, if undefined).

M config/gitlab.yml.example:
  Add 'group' in 'git' section
  Mention default value for the two extra settings
M lib/tasks/gitlab/check.rake:
  Check that gitolite.ssh_user *group* is the one defined in git.group.
  Make sure to default to 'git' as the expected group
    if said group is undefined in the config.
  Note: uses a more complete regexp for the group detection
        (the group can start, end or be in the middle or the list of groups
         of gitolite.ssh_user)
M: config/initializers/1_settings.rb:
  Add default values for gitolite.group and gitlab.user

All overrides are marked as deprecated.
Default settings are at the bottom.

Rewrite build_url, use web_protocol for repo indicator.

Explicitly initialize custom port to make the logic obvious.

Should no longer freak out when omniauth settings aren't present in
gitlab.yml. People who aren't using it shouldn't even have to put a
'false' entry in their config for it (and probably wouldn't, after an
upgrade).

Merge branch 'master' into non-interactive-aws-install

Conflicts:
	doc/installation.md

Fix merge mess in installation.md

New config option: git_hooks_path

Closes #1237

of 'gitlab.yml'.

gitlabhq\config\initializers\1_settings.rb looks for
'gitolite_admin_uri' in the 'git' section of 'gitlab.yml'

Actually, that setting is in the 'git_host' section.
If not fixed, the 'gitolite_admin_uri' would always be equals to
'git@localhost:gitolite-admin', even if the administrator wants
to have another user than 'git' in charge of that repo.