Allow coroutines to fail without destabilizing the app

[BenHenning]

Is your feature request related to a problem? Please describe.
When coroutines fail, they trigger their outer coroutine scope to enter a failure state. This is unexpected: it results in background failures causing all subsequent background tasks to stay failing preventing the app from working correctly anymore.

Describe the solution you'd like
We should:

• Log & track exceptions in background tasks
• Propagate that failure to the UI so that it can respond or show something to the user
• Continue background execution by leveraging a SupervisorJob

For the most part, background execution happens via DataProviders, so this solution probably just needs to be built into NotifiableAsyncLiveData. We actually do want failures of children coroutines to trigger an outright failure of the job (including across transformed or combined data providers), but we don't want an independent background DataProvider operation to trigger a failure in an unrelated DataProvider.

Describe alternatives you've considered
SupervisorJob seems to be the mechanism invented for this purpose. Two alternatives might be:

• Introducing a general purpose task system (effectively reinventing SupervisorJob or coroutines)
• Not use coroutines (similar to above)

Both of these approaches seem harder & more involved than leveraging SupervisorJob.

Additional context
Lots of reading material on the issue:

• https://proandroiddev.com/managing-exceptions-in-nested-coroutine-scopes-9f23fd85e61
• Async builder and cancellation in structured concurrency  Kotlin/kotlinx.coroutines#763
• App exits after catching exception thrown by coroutine Kotlin/kotlinx.coroutines#753
• Scope for "one-for-one" supervision (children don't crash parent and siblings) Kotlin/kotlinx.coroutines#576
• https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-supervisor-job.html
• https://kotlinlang.org/docs/reference/coroutines/exception-handling.html#supervision

[BenHenning]

NB: I suspect this is the reason we were seeing the app stop working when priming was enabled and a failure was encountered. We probably have seen this in a few places without realizing what the underlying cause was. This fix should significantly improve the stability of the app.

[BenHenning]

Also, per SupervisorJob documentation a child failure does not affect other children, so some thought needs to be put into how to handle failures in a chained DataProvider case (or even a standard DataProvider suspend function calling other suspend functions, triggering the creation of child coroutines).

[BenHenning]

Also: the AsyncResult part of DataProviders may be partly hiding this by aggressively catching exceptions to propagate exceptions.

[BenHenning]

For context, I discovered this when trying to implement a CoroutineExecutorService for interop with Java services that needs to rely on ExecutorServices for async operations and that we want to coordinate with our test coroutine dispatchers (e.g. Glide).

[BenHenning]

https://kotlinlang.org/docs/reference/coroutines/exception-handling.html#supervision-scope may be a better way to go in general since it lets us hook into async in cases when we want Deferred, and avoids needing to manually implement a cancellation policy. This also implements closer to we want: all children are cancelled if one fails, but the parent stays unaffected.

[BenHenning]

Actually, it occurs to me all we might need to do is ensure there are different scopes for each independent thing that we want to execute. I think that better fits the paradigm for structured concurrency.