Introduce thread-safe MediatorLiveData or alternative

[BenHenning]

See AsyncDataSubscriptionManager and NotifiableAsyncLiveData for context. NotifiableAsyncLiveData currently relies on MediatorLiveData to chain CoroutineLiveDatas together to properly pipe coroutine-fed data to the UI. However, adding and removing sources from MediatorLiveData must be done on the main thread since the internal sources data structure is not thread-safe, and it calls through to LiveData's observeForever() method which must be called on the main thread.

This requires triggering DataProvider changes on the main thread, which is definitely not ideal. There are two possible alternatives:

• Introduce a custom MediatorLiveData which facilitates an internal, thread-safe structure for monitoring LiveDatas; observer registrations can be batched on the main thread across multiple MediatorLiveData instances to minimize main thread hops
• Introduce a new LiveData sub-class which replaces the MediatorLiveData-CoroutineLiveData mechanism that avoids the observeForever() call, resulting in no thread hop until the final postValue() call on the LiveData for delivery to UI observers

The latter solution seems preferable since it minimizes UI thread hops, but it does result in creating a custom long-lived CoroutineLiveData.

[BenHenning]

This is related to #72 and is blocked on #6.

[BenHenning]

It appears the current MediatorLiveData approach can result in incorrect downstream behavior. Consider the following situation:

1. A dataprovider-turned-livedata is being observed
2. An async operation triggers a change in the data provider
3. The data provider initiates an async operation in a different scope and waits on it
4. The operation in the other scope asynchronously notifies that the data provider has changed
5. Before the operation completes, mediator live data removes the old courotine live data source cancelling the future
6. The async operation completes with a cancellation, and the result is lost (though the async operation from the other task is presumed to complete successfully)

This was found during #122 when a partially-complete progress controller implementation tried to notify observers of a data provider change within the data provider.

The implementation was able to work around this by avoiding the notification during the data provider callback, however this did expose a real issue with this multi-livedata approach for propagating coroutine results to the UI. There should be a simpler, more performant, and correct way to tie coroutines to LiveData without using MediatorLiveData.

[BenHenning]

Correction: the workaround didn't work. It may be that any situation where another scope is combined with a data provider that cancellation is highly likely whenever the mediator live data is notified of a change. This isn't correct: pending jobs should not be cancelled just because a change on the data provider can now be observed.

[BenHenning]

The workaround in the meantime will be to move execution for the progress controller back to the main thread and use a standard lock for synchronizing thread access for shared state. This issue will block introducing the more performant option. We'll keep the interface fully asynchronous to support this solution in the future.

[BenHenning]

#122 also introduced a DataProvider wrapper for Deferred which might be nice to reintroduce, but it needs to be really carefully considered since it may have downstream implications for this mediator mechanism. That provider looked like the following:

  /**
   * Returns an in-memory [DataProvider] which wraps the specified [Deferred] and provides either its successful value
   * or its resulting failure.
   */
  fun <T> createDeferredDataProviderAsync(id: Any, deferred: Deferred<T>): DataProvider<T> {
    return createInMemoryDataProviderAsync(id) {
      try {
        AsyncResult.success(deferred.await())
      } catch (e: Exception ) {
        AsyncResult.failed<T>(e)
      }
    }
  }

[BenHenning]

I think #928 resolves this, though the deferred cases will probably need to be considered later once we have an opportunity to test those (there are other issues related to that that may cause issues, like coroutine cancellation).