Expose ribActionEvents stream

[FranAguilera]

Description:
Expose ribActionEvents stream that emits state of each RIB "action" (e.g didBecomeActive, willLoad) For example:

Event to be emitted just before didBecomeActive
Interactor.didBecomeActive internal call
Even to be emitted after didBecomeActive call is completed

One example application of consuming these events is monitoring binding duration of Workers as shown in ApplicationLevelWorkerLogger from rib-workers demo app
...

WARNING: [RibEvents.enableRibActionEmissions] must be called at the earliest app scope before subscribing/collecting ribAction events. This is intentional in order to avoid unnecessary object creations for each RIB action in case no one is listening

Breaking changes:

Change	Notes
WorkerBinder.initializeMonitoring	Removed. Moving forward can use new flow API
WorkerBinderListener	Removed. Moving forward can use new flow API
RibEvents	Converted to Object, no need for Singleton from now on
RibEvent	Named to RibRouterEvent
events within RibEvents	Renamed events to routerEvents

Tests

• JUnit tests
• Manual validation on internal repo
• Demo on rib-workers sample app
  

Related issue(s):

Provide a new RibActionEvent stream that will allow for monitoring/logging options for all RIB components (Interactor, Presenter, Router, Worker)

[psteiger]

As discussed offline, we could have a DSL like:

inline fun record(startEvent: StartEvent, endEvent: EndEvent, block: () -> Unit) {
  // emit start event
  block()
  // emit end event
}

And in interactors (e.g.) we could have

fun didBecomeActive() {
  record(Interactor.Start, Interactor.Stop) {
      // code for didBecomeActive
  }
}

If we don't do the calculation on the record, and instead do it on consumer side, we can offload the calculation to a worker thread.

Also, we could have an atomic identifier for each record call, incremented at every call, making us sure that the 'end event' corresponds to a certain 'start event' (if needed)

[tyvsmith]

Coroutine Worker? Why reserve for next release?

[FranAguilera]

We may need to tweak a bit more RibCoroutine worker in order to provide accurate monitoring as mentioned by @psteiger earlier

Given there are barely any users internally of RibCoroutineWorker, I'm not concerned to leave these changes to be implemented on a separate PR

[tyvsmith]

Can we lock this down more than T? With the use of lambda's, this, it, and T here it seems like the risk is high that we end up not tracking the correct class we're expecting.

Is there a common interface we can use here? If not, should we have one?

[FranAguilera]

Good idea, let me explore

[FranAguilera]

Added a "RibComponent" contract for these common components, still thinking a better naming for this

[FranAguilera]

I would like to specify a property on the new RibComponent to be overriden, unfortunately given that Worker and RibCoroutineWorker are interfaces we cannot restrict visibility of those

[tyvsmith]

Probably too generic for a name for this set of callbacks. How about something more explicit around emitting callbacks around lifecycles, like RibEventEmitter?

[FranAguilera]

Good idea, I like this better

[FranAguilera]

Decided to go with RibActionEmitter to avoid confusion with existing RibEventType