[ECO-5013] feat: Implement room lifecycle monitoring

[sacOO7]

1. Implemented thread-safe ScopeEmitter ( Behaviour might look same as Hot Flows, but it avoid problems associated with hot flows. Added comment -> [ECO-5013] feat: Implement room lifecycle monitoring #94 (comment)
2. Added impl. for the same as a part of RoomLifeCycleManager

[github-actions]

Code Coverage

File	Coverage [91.39%]
chat-android/src/main/java/com/ably/chat/Emitter.kt	95.35%
chat-android/src/main/java/com/ably/chat/RoomLifecycleManager.kt	90.82%

Total Project Coverage	86.30%	✅

[ttypic]

I don’t think we need this, as we’re essentially reinventing Flow here. Additionally, we’re missing some crucial points in the ScopedEmitter implementation. In its current form, listeners will be invoked non-sequentially, which can be misleading.

[sacOO7]

I was hoping we could have a discussion about this eventually. I don't think we're trying to reinvent the wheel here, though the implementation might resemble shared or hot flows.

Unlike cold flows, hot flows continue emitting values even if no one is actively collecting them. This can lead to situations where the flow keeps emitting values even when the component is in the background, which could potentially cause memory leaks.

Additionally, the flow API is well-suited for use in coroutine-based functions, as both emit and collect are suspending functions. On the other hand, tryEmit can be used in non-suspending functions (like the channel.on method here), although it's generally not recommended.

Since tryEmit() is not a suspending function, it requires a buffer to store the emitted values until they are processed by subscribers. To make this work, we need to set the buffer size to unlimited, but this can affect performance and slow down other subscribers.

Another challenge is canceling flows, as there’s no guarantee that queued events will be delivered when cancellation occurs.

I'll create a separate thread to dive deeper into this and explore how the Emitter implementation can be leveraged for the existing public API to handle messages and presence events asynchronously on the Dispatchers.Default scope, as opposed to relying on the current blocking subscribers.