Fix launchPagingStore

[matt-ramotar]

Closes #602

Description

The cause of #602 is we were not synchronizing updates to single items with the collection they belong to. This PR fixes that by handling the streaming and updating of single item data within a collection.

Other changes:

• Introducing Pager, PagingData, Joiner, Streamer, and KeyFactory interfaces. I think this is cleaner, easier to reason about, easier to test.
• Moving launchPagingStore into RealPager implementation.
• Emitting a state flow of PagingData rather than StoreReadResponse. My thought is this will make it easier to support UI-level extensions, similar to collectLazyPagingItems.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• This change requires a documentation update

Test Plan

• Unit tests

Checklist:

Before submitting your PR, please review and check all of the following:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective
• New and existing unit tests pass locally with my changes

Additional Notes:

• I removed the original design doc from the source code. It is still attached to the PR that introduced paging. I am working on Migrate website to Docusaurus #595 and plan to include documentation on paging internals.
• @digitalbuddha @yigit - I'm launching a child coroutine for each single in a collection. I think this will not scale well for apps with lots of data. We should think about limiting the number of concurrent coroutines and cancellation strategies.

[yigit]

just for readablility, it would be nicer to move these into helper methods.
especially, it is hard to visually track mutexForAllStreams usages without separate methods.

launchChildCollectionLocked

kind of interface might be good.

alternatively, you can use a helper method to create the coroutine (lazily) and then only start it if you can get the lock (e.g. allStrams[key] is null).

[yigit]

so, i'm guessing this is for individual item updates (just double checking).

This was a request in paging, the ability to notify single item changes. But we've never implemented it and it is really hard (since item data change might change ordering). Ideally, instead of observing each child individually, it would be better to let streamer do that job. Technically, I think the streamer should be responsible to emit a new value when any elements matching the data set is changed.

Since I've not looked at store for a while, i might be widely wrong :D. But it feels like better to avoid watching every single child individually, also knowing that, room/sqldelight both will send notification when anything in the table changes, not necessarily an individual item.

[yigit]

another option for individual element watching is is to make streamer(key) return a list of ids and fetch those ids individually (that is how firebase paging works, or worked at some time :) ).
otherwise, i think it is better for streamer to invalidate everything properly instead.

[matt-ramotar]

Moving the responsibility of listening for child updates from RealPager to the streamer makes sense. I also like that users will be able to decide for themselves what level of granularity in observing updates.

[yigit]

i think we shoiulda void child collectors. but if we cant, you can do this better by making their jobs a child of mainJob so that you won't need manual cleanup.

[hoc081098]

combinedItems's type should be List.
And toMutableList is unnecessary when using List type

[matt-ramotar]

Closing. See #611