Before this, we were only adding the correlation id to the "acceptable
exceptions" which we handle in code.

But we need to add it to the default raven context so the information
would be available for uncaught exceptions.

This change is a fairly straightforward refactor to extract the tracing
and correlation-id code from the gitlab rails codebase into the new
LabKit-Ruby project.

The corresponding import into LabKit-Ruby was in
https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1

The code itself remains very similar for now.

Extracting it allows us to reuse it in other projects, such as
Gitaly-Ruby. This will give us the advantages of correlation-ids and
distributed tracing in that project too.

Updates specs to use new rails5 format.

The old format:
`get :show, { some: params }, { some: headers }`

The new format:
`get :show, params: { some: params }, headers: { some: headers }`

The Correlation ID is taken or generated from received X-Request-ID.
Then it is being passed to all executed services (sidekiq workers
or gitaly calls).

The Correlation ID is logged in all structured logs as `correlation_id`.

Adds gitlab.impersonation_enabled config option defaulting to true to
keep the current default behaviour.

Only the act of impersonation is modified, impersonation token
management is not affected.

This will make it clearer to users which account is being used to make
the API/git call. So they know which account needs to be used to
accept the terms.

Closes #46649

When terms are enforced, but the user has not accepted the terms
access to the API & git is rejected with a message directing the user
to the web app to accept the terms.

This will enable admins to identify who actually made the API request.

Relates to #36960

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

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

- Scope declarations of the form:

    allow_access_with_scope :read_user, if: -> (request) { request.get? }

  will only apply for `GET` requests

- Add a negative test to a `POST` endpoint in the `users` API to test this. Also
  test for this case in the `AccessTokenValidationService` unit tests.

- Currently, (for example) admins can't delete snippets for blocked users, which
  is an unexpected limitation.

- We modify `authenticate!` to conduct the `access_api` policy check against the
  `initial_current_user`, instead of the user being impersonated.

- Update CHANGELOG for !10842

Removed all the unnecessary include of `WaitForAjax` and `ApiHelpers` in the specs.
Removed unnecessary usage of `api:true`

true is neither nil nor a user and doesn't make sense as the return
value of `current_user`

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