Most of this is hidden behind a feature flag and untested. Still waiting
on server support to exercise these endpoints.
- Builds out skeleton for tracking arbitrary spam challenges
- Records a push challenge in response to a server push
- Records a captcha challenge in response to a server precondition
rejection when fetching prekeys or sending messages
Push challenges should be good to go (once tested). Captcha challenges
still require some work to pause sending and present the captcha to the
user. Server communication for captcha challenges is complete.
We still need the AxolotlKit model classes to migrate old sessions,
but we don't need any of the actual protocol support. This also
means we can drop HKDFKit.
Additionally, we do still use some utilities from AxolotlKit:
- AxolotlExceptions.h: NSException names, should eventually be
replaced by NSErrors everywhere
- NSData+keyVersionByte.h: prepend/remove public key type byte,
should eventually be replaced by strong types (ECPublicKey)
- SPKProtocolContext.h: defines the SPKProtocol{Read,Write}Context
marker protocols, should be replaced by direct use of
SDSAny{Read,Write}Transaction
- 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.
