[ECO-4953][CHA-RL7] Executor for mutually exclusive room lifecycle operations

[sacOO7]

• Part of Chat Room: implement room lifecycle spec #6
• Currently, chat spec explicitly defines to perform mutually exclusive lifecycle operations.
• This includes internal retry, attach, detach, resume etc, more might come in the future.
• Current implementation mimicks prioritized execution of operations same as defined in chat-js ( can be changed to simple queue in the future if needed )
• Although, this is not mentioned in the spec, aim to is to keep code totally in sync with chat-js.
• This will also help with testing using UTS where expected behaviour / assertions will be mainly derived from chat-js functionality.

TODO -

• Need to add tests

[ttypic]

I believe this code does nothing, because all delays inside runTest are skipped, see

[sacOO7]

I agree, runTest skips use of delay.
But, that's only true when code is run in the context of a given test coroutineScope.
Since we are passing custom CoroutineScope, this doesn't skip delay.
You might like to run the test on the local by changing values to say
delay((2000..2100).random().toDuration(DurationUnit.MILLISECONDS))

[sacOO7]

Test will take more time to run

[ttypic]

missed it, you are right! But nevertheless do we really need any of this delays? Not sure delays make tests more reliable

[ttypic]

I believe it's better to use framework's implementation for deferred value - CompletableDeferred

[ttypic]

I believe implementation of this class implies single-threaded coroutine context, but there is no restriction in public API, which is not very good. Also it's hard to understand how it will be used later. I am a bit skeptical about this scheduler which is pretty low-leveled, I would prefer built-in kotlinx.coroutines tools. In my head it's something like this

class RoomLifecycleManager {
  private val internalEvents = Channel<InternalEvent>(Channel.UNLIMITED)
  private val attachmentEvents = Channel<AttachmentEvent>(Channel.UNLIMITED)
  private val releasingEvents = Channel<ReleaseEvent>(Channel.UNLIMITED)

  init { subscribeToIncommingEvents() }  

  fun attach() {
     subscribeToContributorsStateChange()
     dispatch(AttachmentEvent.Attach)
  }
  
  fun detach() {
     dispatch(AttachmentEvent.Detach)
  }

   private fun subscribeToIncommingEvents() {  
     withContext(singleThreadContext) {
         while (active) {
                select {
                    internalEvents.onReceive { event -> 
                        processInternalEvent(event)
                    }
                    attachmentEvents.onReceive { event -> 
                        processAttachmentEvent(event)
                    }
                    releasingEvents.onReceive { event -> 
                        processReleasingEvent(event)
                    }
                }
            }
        }
   }
}

[sacOO7]

Official documentation mentions API is experimental -> https://kotlinlang.org/docs/select-expression.html.
Though latest release might have made it stable

[sacOO7]

I will go through the documentation again. This is a good idea to use.
Also, it fits our requirement of prioritized execution according to the spec

[sacOO7]

I will create a new PR for this. We will see how complicated this can get.
The main issue is dealing with while(active) loop.
We need to keep track of room getting released and if there are any pending events as such : (

[sacOO7]

Created PR based on suggestion implementation -> #31

[sacOO7]

This PR is superseded by #32