Add hello-world Go executable and gitaly-proto 0.5.0

assigned to @jacobvosmaer-gitlab

As a next step I wanted to add an external library and vendor it. My goal here is to get some of this annoying plumbing out of the way before someone else on the Gitaly team gets to do the interesting stuff.

But, now I am starting to see some of the consequences of this 'gitlab-shell has Go executables' idea.

it’s easy to make something that can compile for production installations

[6:02] but, development

[6:02] the current situation is that gitlab-shell sits in /gitlab-shell in GDK

[6:02] that does not make for good GOPATH integration

[6:02] the patter we follow so far is that each Go project in GDK has its own GOPATH

[6:02] e.g. gitlab-workhorse has GOPATH /gitlab-workhorse

[6:03] and the actual workhorse code sits in /gitlab-workhorse/src/gitlab.com/gitlab-org/gitlab-workhorse

[6:03] what makes me hesitate is the idea of inflicting this on gitlab-shell developers

I might be wrong, but I now get the feeling to make gitlab-shell/go not suck for Go developers, we have to make gitlab-shell look like a Go project in GDK. Which sucks for Ruby devs. :(

hmm

[6:19] maybe we could do a hack. put gitlab-shell into GDK the same way we do with workhorse, only under /go-gitlab-shell. and then make /gitlab-shell a symlink to /go-gitlab-shell/src/gitlab.com/gitlab-org/gitlab-shell

I will play around in GDK to see if that hack works.

https://gitlab.com/gitlab-org/gitlab-development-kit/merge_requests/282

I am optimistic this will work out in GDK. Next step is to flesh out the GDK stuff, and to add a non-stdlib library on this end just so that problem is solved already.