- Removes ContactsUpdater singleton. It wasn't really tracking much
state anyway
- Introduces ContactDiscoveryTask. This creates a
ContactDiscoveryOperation (modern or legacy) and updates the
SignalRecipients database on completion. Returns a promise.
- Begin migrating away from operation queues
PromiseKit is weird about priority propogation, so this shouldn't be
used yet. Since all then closures are asynced, priorities don't
propogate down to underlying queues. This means the a
ContactDiscoveryTask on the main queue will not boost the priority on
the ModernContactDiscoverOperation's owned operation queue
Creates a new root singleton: OWSMessagePipelineSupervisor
As of right now, this singleton has two responsibilities:
- Track all message processing pipeline stages that have registered
themselves
- Post processing suspension updates to interested stages
Four classes will now register themselves as pipeline stages:
- OWSMessageContentQueue
- YAPDBMessageDecryptQueue
- IncomingGroupsV2MessageQueue
- SSKMessageDecryptJobQueue
At initialization, OWSMessagePipelineSupervisor will take out a pipeline
suspension while it waits for a UUIDBackfillTask to complete. Other
interested objects are also able to suspend the message processing
pipeline by invoking suspendMessageProcessing(for:) on the supervisor
(though, currently this is not used by anything except tests)
This also adds some supporting improvements to UnfairLock. Now,
UnfairLock closures will return the value returned from its critical
section closure.
- Removed static UUIDBackfillTask initializer and removed the
registration from AppDelegate. Kicking off the task will be handled
with IOS-631.
- Moved the async perform work to its own function
- Some minor syntactic changes
- Updated database fetch to retrieve empty string UUIDs
- Handles non-e164 numbers fetched from database
- Leverages the MockSSKEnvironment to deal with the shared
SignalServiceAddressCache. Removes added test support.
- Add tests to exercise new functionality
The NSE should only run on iOS 13.3 or later where the "filtering" entitlement
is available since our notifications don't contain any content and will often
not trigger any user visible content. We control this by setting the deployment
target to iOS 13.3.
This does not handle calls as it's currently impossible to wake the main app or
launch CallKit from within the NSE. Should we reach a point where we need to use
this extension in production the service will need to be able to differentiate
between call and non-call messages and deliver them as VOIP or Vanilla pushes as
appropriate. Alternatively, Apple may introduce some way for us to signal the
main app that a call message has been received.
This does not currently address the potential for the NSE and the main app to be
running and trying to process messages at the same time. As long as the
websocket is connected and the main app is processing messages in a timely
fashion the NSE will never be called since the service will not send pushes for
these messages, but censorship circumvention users and users where the websocket
is disconnected for some reason will legitimately receive pushes and we will
want to process those messages. How we will handle these cases requires further
thought since just terminating the NSE when the app launches is not sufficient.
We could potentially do something like terminate the NSE everytime the main app
runs the message fetcher job which should only happen if either the user
pulls-to-refresh on the conversation list or the websocket is actively connected
and receiving messsages. I plan to address this in a follow-up pull request.
Currently this code will not ever be run since the service never sends vanilla
push notifications. Eventually we will need to add logic into the main app to:
a) detect we're on iOS 13.3 or later and b) update a flag on the service telling
it to stop using VOIP pushes for non-call messages. The API for requesting this
from the service does not yet exist.
* Modify message processing to allow observation of websocket queue being drained.
* Extend MessageProcessing to allow observation of REST message fetching and "all message fetching and processing".
Tests from `receivedEnvelopeData`, which is called by e.g. the websocket or the
messageFetcherJob through the message processing pipeline until the UIDatabase
is notified with the new message and thread.
Includes some test helpers to initialize sessions and encrypt/decrypt messages.
