Add logger for CLI telemetry

[shreyas-goenka]

Changes

Replaces #2037.

This PR adds a telemetry logger library that allows us to log arbitrary events as long as a corresponding proto exists in the universe.

We add a timeout of 3 seconds for logging the telemetry. Manual benchmarks show that API requests can take anywhere from 1-3 seconds to finish. We start here with a pragmatic approach and can improve this it of the UX in either of two ways:

1. Add a new command to publish telemetry, and spawn a new process so that the main process can exit without waiting for the telemetry to publish.
2. Maintain a warm TCP connection so that logging the telemetry will only take the round trip time and avoid the overhead associated with

Tests

Integration and unit tests.

[shreyas-goenka]

In the future, this function could spawn a new process to avoid the latency cost altogether. Flushing the events to disk and having a new process consume them seems more reliable than this timeout based approach.

[shreyas-goenka]

Integration tests are green.

[denik]

What's the purpose of this typecheck here? Why panic (as opposed to logging a message).

[shreyas-goenka]

Reaching here typically is a developer error. Panicking informs the developer there's a problem without having to return and propagate the error. For example, we also panic here: dbr.RunsOnRuntime(ctx)

We do the type check because we do not want to error or override if a mock logger is configured.

[denik]

Why do we need mockLogger? The real logger already accepts interface for API call, which can be no-op in tests.

[shreyas-goenka]

I wanted to avoid adding the Introspect() method to the real logger and limit it's usage to strictly unit / integration tests.

With the mock logger you can also directly assert on a typed object for the logs / events. If we do the assertions on the apiClient directly (like we did in libs/telemetry/logger_test.go) then you need to assert on the serialized JSON strings for the events.