Release v1.0.0

See merge request !82

Add "quick facts" section

Towards https://gitlab.com/gitlab-org/gitlab-workhorse/issues/75

See merge request !79

Adds Unix signal to reopen log file

This MR adds a command line flag to provide a log file and creates a handler to reopen the log file upon receiving a SIGHUP signal.

A new dependency is also added: [github.com/client9/reopen](https://github.com/client9/reopen)

Relevant Issue: [#52](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/52)

cc: @jacobvosmaer-gitlab, @smcgivern 

See merge request !77

  - Adds new logFile flag
  - Adds client9/reopen dependency
  - Enables log file reopening on SIGHUP
  - Adds a custom response logger

Improve error messages

Less noise from 'deepen' inspection. Better grouping of 'bad gateway' errors.

See merge request !76

Hopefully this will lead to better grouping of errors in Sentry.

They are just noise.

Change the revspec for `git format-patch`

For merge requests, GitLab currently sends:

* ShaFrom == tip of target branch
* ShaTo == tip of source branch

This MR adds tests for this scenario and the alternative:

* ShaFrom == base SHA
* ShaTo == tip of source branch

It then makes the test for the first case pass by altering the revspec. 

What to do with diffs is still an open question, so we leave those untouched for the moment.

See https://gitlab.com/gitlab-org/gitlab-ce/issues/22229

See merge request !68

Print go version during CI build



See merge request !74

Resolve "http.StatusTooManyRequests breaks Go 1.5 compatibility"

This merge request replaces a constant introduced in go1.6 with its literal value, as we need go1.5 support. No other changes are required.

It also modifies .gitlab-ci.yml to test against go1.5, 1.6 and 1.7, to prevent future regressions.

Closes #69

See merge request !73

Allow to queue API requests and limit given capacity

This MR implements an API queueing on Workhorse side.
It's meant to better control given capacity for different resources.

This is meant to solve: https://gitlab.com/gitlab-com/infrastructure/issues/320.

And make a large number of requests easier to handle: https://gitlab.com/gitlab-org/gitlab-ce/issues/21698

It fulfils these requirements:
- allow to limit capacity given to API, specifically to allow to process up to N-number of requests at single time,
- allow to queue API requests and timeout them, specifically it allows to slow down processing of API calls if the Unicorn can process the current API requests in reasonable time

The implementation is made as constant cost and it's dead simple.
It should not inflate the memory / CPU usage of Workhorse.

It works like this:
- we hook into processing of requests,
- we try to acquire slot for our request by pushing to buffered channel. The buffered channel actually limits number of processed requests at single time,
- if we can't push to channel it means that all concurrent slots are in use and we have to wait,
- we block on buffered channel for the free a slot, secondly we wait on timer to timeout on channel,
- we generate 502 if timeout occurs,
- we process request if we manage to push to channel,
- we pop from channel when we finish processing of requests, allowing other requests to fire,
- if there's already too many request (over `apiQueueLimit`) we return 429,

This introduces 3 extra parameters (off by default):
- `apiLimit` - limit number of concurrent API requests,
- `apiQueueLimit` - limit the backlog for queueing,
- `apiQueueTimeout` - duration after we timeout requests if they sit too long in queue.

This allows:
- limit used capacity to any number of available workers, ex. allowing for API to use at most 25% of capacity,
- slowly process requests in case of slowness,
- better manage the API calls then rate limiting requests,
- by slowing down we are automatically backing off all services using API,


See merge request !65

Expose three options to configure queueing limits:
- apiLimit
- apiQueueLimit
- apiQueueTimeout

Suppress upload-pack Wait() error on shallow clone

Closes https://gitlab.com/gitlab-org/gitlab-workhorse/issues/36

It is a [known
bug](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/36#note_4761298)
in git-upload-pack that it exits unsuccessfully when the client does a
'shallow clone'. We don't want this non-zero process exit status to
clutter our logs. In this change we buffer the first 4kB of the request body for
git upload-pack and scan for a 'deepen' message (which indicates the
clients wants to do a shallow clone). If deepen is found we suppress
error reporting for a non-zero exit status of git upload-pack.


See merge request !71

Improve errors

- Add request metadata (method, path)
- Sentry improvement: custom types for common errors

Closes https://gitlab.com/gitlab-org/gitlab-workhorse/issues/64

See merge request !69