Feature: allow logger configuration and propagation through the call stack

[pmalek]

Related TODO comments:

• kubernetes-telemetry/pkg/telemetry/consumer.go

  Line 91 in 8884711

  logger = defaultLogger() // TODO: allow configuration

• kubernetes-telemetry/pkg/telemetry/consumer.go

  Line 30 in 8884711

  logger = defaultLogger() // TODO: allow configuration

[rainest]

We currently instantiate (non-configurable) loggers for both the manager and consumers (see https://github.com/Kong/kubernetes-telemetry/blob/v0.1.0/pkg/telemetry/manager.go#L59 and https://github.com/Kong/kubernetes-telemetry/blob/v0.1.0/pkg/telemetry/consumer.go#L31-L32).

Applications using this library instantiate consumers independent of their manager, but ultimately add those consumers to the manager. IDK if there's any case where you'd use a consumer independent of a manager, but I don't think there is.

My intuition is that there's probably no reason for the consumers to manage their own logger, and that it'd make sense to somehow refactor them to use the logger of the manager they're added to (either they log nothing and only return things for the manager to log, or that they expect a manager that always provides them with a logger that it has in turn received from something else). Are there any use cases where the consumer logger needs to both exist and exist independent of a manager?

[pmalek]

Are there any use cases where the consumer logger needs to both exist and exist independent of a manager?

Not really. It's just how it was made in the initial version.

We'd need to come up with a way of creating the consumer without the knowledge about the manager but then when adding the former to the latter to inject the logger, allowing the consumer to default to something sane like a noop logger (which we hold the value until added to manager) to prevent things like nil checks every time the consumer is about to use the logger.