[logging] Enable storing/extracing of logger from context

[easyCZ]

Description

This adds helpers to:

• Add a logger to a context
• Extract a logger from a context
• Both of these are just aliases to an upstream implementation from https://github.com/grpc-ecosystem/go-grpc-middleware/blob/v1.3.0/logging/logrus/ctxlogrus/context.go#L36

Why?
With the logger on the context, we gain the ability to have request scoped fields on the logger. This means that we can add more fields to the existing context and these will be logged when we actually use the context logger to log.

To better illustrate this:

1. Request arrives at a server
2. The request first runs through a middleware, the middleware attaches the (request ID, path, params, ...)
3. The handler gets invoked. The handler first checks if an experiment is enabled, and attaches that value to the context logger through fields
4. The handler returns an error
5. The middleware picks up the error, and logs it. When this happens, the log also contains the attached information about the experiment not being present, as well as (request ID, etc..)

I will update the public api to use the context logger in subsequent PR

Related Issue(s)

Fixes #

How to test

Release Notes

NONE

Documentation

Build Options:

• /werft with-github-actions
  Experimental feature to run the build with GitHub Actions (and not in Werft).
• leeway-no-cache
  leeway-target=components:all
• /werft no-test
  Run Leeway with --dont-test

Publish Options

• /werft publish-to-npm
• /werft publish-to-jb-marketplace

Installer Options

• with-ee-license
• with-slow-database
• with-dedicated-emulation
• with-ws-manager-mk2
• workspace-feature-flags
  Add desired feature flags to the end of the line above, space separated

Preview Environment Options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-gce-vm
  If enabled this will create the environment on GCE infra
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh

[easyCZ]

The go.mod diff is silly, but it's because common-go/log is used by all packages.

/hold for discussion, if needed

[mads-hartmann]

From an instrumentation perspective this seems like an excellent addition! 🎉 Even though it's only 3 lines of code, and all it does is delegate to another library, I would have loved a tiny test of it - if it's not too much trouble to add that would be lovely, but I'll approve and leave that decision with you ☺️

[easyCZ]

@mads-hartmann added a test. Thanks!

[akosyakov]

Just to clarify it for myself:

• it allows to hook our logrus logger with additional fields in grpc middleware
• it is not used by default, but there will be follow up PRs to integrate

?

[easyCZ]

@akosyakov Yes. It uses the context to attach a request-scoped logger & fields to it. This means that any fields we add are part of that request lifecycle.

Yes, not yet used by services. I've a follow-up PR which adds it to public-api to demonstrate the usage (not yet complete).

This then means we can magically have extra context on the log lines. One of the most powerful parts of this is when we attach the trace ID on the log context, and then we can lookup all logs for a given request, even across services (because the tracing ID is propagated)

[akosyakov]

no objections from my side

[easyCZ]

/unhold