Create Logger Abstraction for Ably Chat SDK

[ttypic]

We need to create a flexible and configurable logger abstraction for the Ably Chat SDK that integrates smoothly with Android’s default logging system and allows for custom logging handlers to be set via Chat Client's ClientOptions. This will provide users with better control over logging behavior and allow them to intercept or handle logs in a way that suits their needs.

Requirements:

1. Android Default Logging:
   By default, the SDK should use Android’s native logging system (e.g., Log.d, Log.i, etc.) for logging events.
2. Custom Logger Handler in Chat's ClientOptions:
   • There should be special logHandler property in the ClientOptions with the type (message: string, level: LogLevel, context: LogContext?) -> Unit
   • There also should be logLevel property that filters logs based on log level
3. Independent Logging for multiple ChatClient Instances:
   • If two or more instances of ChatClient are created, each instance should have its own separate logger handler if specified in the respective ClientOptions.
   • Logs from one instance should not interfere with or affect the other instance’s logging.
4. (Optional) Think how to support slf4j, we are going to make Chat SDK JVM library (once we refactor ably-java)

┆Issue is synchronized with this Jira Task by Unito

[sacOO7]

Thanks for specifying the Requirements. We can both agree that the logging helps to debug and understand the execution flow of the application. I would like to mention a few points that should help us achieve this goal.

1. We will have a default logger, initialized at the root level ChatClient. So, it should initialize with following context =>

• ClassName - Full packagename.classname
• Timestamp - timestamp integer value.
• ConnectionId - realtimeClient.connection.connectionId ( we do this in ruby, really helps with debugging )
• ClientId - realtimeClient.auth.clientId
• ThreadId+CoroutineName - Check https://kotlinlang.org/docs/coroutine-context-and-dispatchers.html#debugging-using-logging
  When this context is set onto logger, that means for every message logged, context fields will be populated by default.

3. When the logger is passed to corresponding properties of ChatClient -> rooms -> room -> messages , presence, typing, it should derive context from the parent. There should be explicit method to derive a child logger that inherits the parent logger context.
   i.e. roomLogger = parentLogger.withContext(newClassName, roomName: roomId); // existing classname will be overridden and additional context will be set

4. The resulting log message should be a JSON-encoded string with key-value pairs. Those key-value pairs can be nested if needed. This is highly recommended because JSON logs are exportable. They can be loaded into Excel sheets, databases or any other analytical tools. Also, JSON makes them easily filterable. We currently have active customer asking us to provide filters for the logs -> https://ably-real-time.slack.com/archives/C8SPU4589/p1729170991262969?thread_ts=1728641491.580499&cid=C8SPU4589

5. Logger should track/avoid logging tokens or can be osculated ( not a high priority ).

I would leave implementation of Logger, LogHandler, LoggerSink to you, but ultimately we should make sure that log messages are readable and provide enough information to debug when things go wrong.

[sacOO7]

Btw, in dotnet we also use localized loggers with parent context,
Like when performing HTTP request, we can initialise localLogger derived from parentLogger. We can set context on it, like requestId, sessionId etc. All following messages logged within the method will have context metadata already set on them.