* Add search backfill worker
This will run on background at most once an hour while the device has internet connectivity and the device is charging and start back-paginating through the user's rooms to make sure the search results are populated.
It'll run for the maximum time the default workers allow, 10 minutes.
* Create `RustMatrixClient.Factory` AssistedFactory to help with DI and add `SearchBackfillService`
* Start search backfill when entering the search screen, just once. This should help getting initial search results if none or few are found at first
Cover the remaining interfaces of libraries/troubleshoot, libraries/matrixmedia,
libraries/dateformatter, libraries/featureflag, libraries/workmanager and
libraries/mediaviewer, along with their members and parameters.
Behaviours worth recording: NotificationTroubleshootTest reports its outcome
through its state flow rather than by returning, and its quickFix throws unless
the test offers one; DateFormatter.format turns a null timestamp into an empty
string so callers need no null check; ImageLoaderHolder keeps one loader per
session because decrypting room media needs that session's client.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- libraries.sessionStorage.api
- projects.libraries.architecture
from `api` to `implementation`.
Modules who need `:libraries:matrix.api` do not necessarily need to use the session storage api.
* Create `PushRequest` in push history DB: this will be used to store requests for push notifications, either pending or completed ones.
* Rename `WorkManagerRequest` to `WorkManagerRequestBuilder`: make its `build` method return a list of `WorkManagerRequestWrapper`, which can be used to enqueue normal or unique workers.
* Rename `PerformDatabaseVacuumRequestBuilder` and adapt it to the new API.
* Adjust other components using `WorkManagerRequest`.
* Replace `SyncNotificationWorkManagerRequestBuilder` with `SyncPendingNotificationsRequestBuilder` and `FetchNotificationsWorker` with `FetchPendingNotificationsWorker`: this new pair of request builder and worker allow enqueuing requests for a session id and, once the worker runs, retrieve all the pending request data and use it to fetch the associated events. This simplifies quite a bit how this data had to be passed or grouped, since it's no longer necessary to do so
* Add new methods to `PushHistoryService` to modify the `PushDatabase`:
- insertOrUpdatePushRequest
- insertOrUpdatePushRequests
- getPendingPushRequests
- removeOldPushRequests
* Make `PushHandler` just handle incoming pushes: those will be inserted into the pending push request table in DB, then handled by the new worker. Once the process finished, a new `NotificationResultProcessor` will handle the results and what needs to be done with them (call ringing, displaying notifications, etc.)
* Add `requestType` optional parameter to `WorkManagerScheduler.cancel` so we can decide to only cancel some kinds of requests.
* Add migration to remove existing work manager requests for fetching notifications, since the previous worker class no longer exists.
* Initial implementation of notification sync using `WorkManager`
* Use custom `MetroWorkerFactory` to allow assisted injection in WorkManager Workers
* Add tests for `FetchNotificationWorker`. Create `FakeNotificationResolverQueue` to help testing.
* Add more tests, fix Konsist checks
* Add tests for `SyncNotificationWorkManagerRequest`
* Simplify `FakeNotificationResolverQueue`
