Fix CI requests concurrency

What does this MR do?

This fixes a bug introduced by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8084.

When we try to update a build, we load it's representation to the memory, in between another update can happen by another Runner. Since we use optimistic locking we will receive an exception stating that our copy of the object is old (StaleObjectError). This exception makes us return nil from RegisterBuildService to builds/register handler.

Since we received nil we assume that we did not found a new build, so, the build queue is empty. However, this is not true, because we only failed to update the existing build.

Runner then will receive the latest value of runner queue (after change), and next time when we ask the builds/register.json we will hit the happy path of processing, assuming that there were no changes to build queue since the last time.

This bug affects GitLab Runners from 1.9.0-rc5 to 1.10.x

Does this MR meet the acceptance criteria?

• Changelog entry added
• Tests added for this feature/bug

What are the relevant issue numbers?

None yet.