Gitlab-shell hooks can no longer send absolute paths to gitlab-ce

The following is all to do with handling git push.

In three places, the gitlab-shell hooks send messages to gitlab-ce where they reference a project by the absolute path to the repository on disk.

• redis message for sidekiq / post-receive
• API post-receive notification
• Merge Requests URLs

Once Gitaly is capable of running on a remote server, we can no longer assume that the mount points of Git repository data drives are the same between the Gitaly server and the server that runs gitlab-ce code. (Eventually, the gitlab-ce server will have no disk access to the repositories at all, but that will be a while.) It may be that the hook, running on the Gitaly server, 'thinks' /exports/storage01/repositories/foo/bar.git is the absolute path to the repository, while it is /mnt/nfs/storage01/repositories/foo/bar.git on the gitlab-ce server.

I think we should solve this problem by letting the hooks use an identifier for the project that is independent of the disk path. It could look like this:

• when pre-authorizing the request, gitlab-shell/gitlab-workhorse receive a project_id value in the authorization response
• gitlab-shell/gitlab-workhorse set a (new) variable GL_PROJECT_ID when spawning git receive-pack
• gitlab-shell hooks pass the value of GL_PROJECT_ID along with their messages to gitlab-ce

We should not remove the old identifier (repo_path) from the messages because that would complicate upgrades, and some messages are delivered asynchronously so they may arrive late.

This issue is blocking https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10150 and gitaly#144 (closed). This issue blocks us from being able to run Gitaly on a remote server, which is something we want for 9.1.