Threading library

[BenHenning]

A threading library should be provided to encourage developers to use it rather than relying on other mechanisms (e.g. raw threads and AsyncTask) which, when used improperly, could result in crashes and other issues. This implementation should provide interop with Retrofit, and integrate well with other async mechanisms deemed safe (e.g. Kotlin coroutines with work managers or mechanisms provided by RX).

If it's needed, this threading library should also provide a lifecycle-safe manager for recurring task handling (maybe using Firebase job manager if these need to be long lived tasks).

[BenHenning]

This is blocked on #4.

[BenHenning]

Although not specifically called out, this work may block downstream work that isn't identified until that work is in the design phase. For that reason, this work should be done as early as possible once its specific technical details are better understood.

[BenHenning]

This was partially implemented in #85. We should resolve the remaining data source work and then determine what's needed here. At the moment, I suspect all we need is a way to easily schedule tasks on a background thread using coroutines and in a way that's interoperable with tests (#89 is related here).

[BenHenning]

Also, consider something like #8. In both Logger and InMemoryBlockingCache, we want a sequential executor for the lifetime of that object, but isolated to that object. However, we also want to be able to carefully control total execution throughput in the app to avoid issues with low-performing devices per the work in #79.

[BenHenning]

This issue is too ambiguous to keep open. We now have a threading library under the util module, and per comments above it's likely to be expanded as needed. No explicit threading support has been identified that requires its own tracking issue, so closing this.