Logging context refactoring

[soareschen]

This PR introduces a new logging context that follows the same pattern as CanRaiseError, to allow for more modular logging implementations.

• A CanLog<Details> trait is provided, with Details being arbitrary struct containing additional details for structured logging.
• An abstract TracingLogger context is provided which implements CanLog for detail types defined in the core relayer-components crate.
• A CosmosLogger and SovereignLogger contexts are provided which implements the specific logging contexts by delegating to TracingLogger. The concrete logging context are different, so that they can be extended to log external detail types.

[romac]

I wonder why we are not using tracing instead of a custom logging implementation? What does the current one gets us that tracing does not? I only see logging of structured values (which is still behind an unstable flag in tracing, but we could fork it and enable it on stable if we wanted to), but perhaps I am not seeing the big picture?

[soareschen]

I wonder why we are not using tracing instead of a custom logging implementation?

A structured logging context would work better for logging with rich details. Both tracing and log have actually started to support structured logging actually, but they are a bit unstable at the moment. (rust-lang/log#613, tokio-rs/tracing#1570).

In any case, the new logging context is agnostic to which logging library is used in the end. In my latest prototype, the concrete logging implementation is concentrated here, which uses tracing: https://github.com/informalsystems/hermes-sdk/blob/soares/logger-refactoring/crates/cosmos/cosmos-client-components/src/impls/logger.rs.

I also tried to implement an alternative logging back end using log and Serialize. But I figured that is probably still not flexible enough, because we may want to pull additional information based on the concrete context and concrete types. So I'd probably abandon that attempt.

With the refactoring in this PR, the main logging implementation would be using tracing and its macro-based structured logging. But at least all the logging methods are concentrated into one file, so we can easily refactor them in the future.

Ideally, my hope is that when something like Valuable is stabilized, we would eventually able to bypass the macros and abstract over the concrete loggers. Note however that the abstract logging context will still remain the same and do not require another redesign.

[soareschen]

Another plan I have for the longer term is to unify the API for logging and telemetry. The idea is that the logging context would also contain the telemetry or analytics back end. So for metrics that we want to collect, it is a matter of customizing the specific logging implementation so that it both logs the message as well as collecting the metrics.

[romac]

Another plan I have for the longer term is to unify the API for logging and telemetry. The idea is that the logging context would also contain the telemetry or analytics back end. So for metrics that we want to collect, it is a matter of customizing the specific logging implementation so that it both logs the message as well as collecting the metrics.

Sounds good, might streamline metrics integration when we get to it 👍