Backport "Pass relevant git environment variables while calling `/allowed`" to 3-6-stable

See merge request !120

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

1. Starting version 2.11, git changed the way the pre-receive flow works.

  - Previously, the new potential objects would be added to the main repo. If the
    pre-receive passes, the new objects stay in the repo but are linked up. If
    the pre-receive fails, the new objects stay orphaned in the repo, and are
    cleaned up during the next `git gc`.

  - In 2.11, the new potential objects are added to a temporary "alternate object
    directory", that git creates for this purpose. If the pre-receive passes, the
    objects from the alternate object directory are migrated to the main repo. If
    the pre-receive fails the alternate object directory is simply deleted.

2. In our workflow, the pre-recieve script calls the `/allowed` endpoint on the
   rails server. This `/allowed` endpoint calls out directly to git to perform
   various checks. These direct calls to git do _not_ have the necessary
   environment variables set which allow access to the "alternate object
   directory" (explained above). Therefore these calls to git are not able to
   access any of the new potential objects to be added during this push.

3. We fix this by passing the relevant environment variables
   (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY, and
   GIT_QUARANTINE_PATH) to the `/allowed` endpoint, which will then include
   these environment variables while calling out to git.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Re-use the default logger for performance metrics

See #64 for the discussion leading up to this.

See merge request !100

This removes the need for configuring anything extra. To make scraping
easier each line is prefixed by "metrics:".

Fixes #64

Instrument GitLab Shell and log metrics data to a file

See merge request !98

Test against ruby 2.3

Closes #61

See merge request !99

Fix rsync with ionice command building

See merge request !97

Fix short circuit logic between rsync with and without ionice for storage migrations

See merge request !96

storage migrations

Re-exposing GL_ID to custom hooks

closes https://gitlab.com/gitlab-org/gitlab-ee/issues/995
closes https://gitlab.com/gitlab-org/gitlab-shell/issues/53

See merge request !95

Update VERSION

Was this an oversight? Should we re-tag v3.6.2? Or just bump to v3.6.3?

See merge request !94

Enable GIT_TRACE_PERFORMANCE through a config variable.

The value of the variable must an absolute path needs to exist so we’re able to check if we can write in that file. Because in the 
case we cannot write we’ll throw a warning to the output of the users.

```sh
~/dev/gitlab/local/pacoguzman/gitlab-ce (master=)$ git push origin master
warning: could not open '/wadus' for tracing: Permission denied
Everything up-to-date
```

Closes #59

See merge request !91

Enable GIT_TRACE/GIT_TRACE_PACKET/GIT_TRACE_PERFORMANCE by providing the git_trace_log_file config key

The value of the variable if present must be a writable absolute path. If it’s
not the case we log a proper message and not enable tracing to not throw output to the users.

Set a low IO priority for storage moves to lower performance impact

See merge request !92

Added LFS support to SSH

Required changes to GitLab Shell include the actual handling of the `git-lfs-authenticate` command and the retrieval of the correct credentials.

Needed for gitlab-org/gitlab-ce!6043

Related to gitlab-org/gitlab-ce#3589

> **Note:** gitlab-org/gitlab-ce!6043 needs to be merged before this one.

cc @jacobvosmaer-gitlab @marin @DouweM

See merge request !86

- Required changes to GitLab Shell include the actual handling of the `git-lfs-authenticate` command and the retrieval of the correct credentials.

Add option to recover 2FA via SSH

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/3765

Allow users to recover their own account if they lose their 2FA device or recovery codes. 

## Questions/Concerns

- Does this look secure? I think it is but we need to make sure no one can spoof a username or something and disable two factor.

## Todo

- [x] Working code
- [x] Tests
- [x] GitLab merge requests (including documentation)

![Screen_Shot_2016-08-18_at_2.34.18_PM](/uploads/1ed00e93abdfc3b41187c021e4f9d4db/Screen_Shot_2016-08-18_at_2.34.18_PM.png)

See merge request !74

Sentinel Support

Sentinel connection parameters in `config.yml` file.

Fixes #29

See merge request !85