PreKeyRecord, PreKeyBundle, and SignedPreKeyBundle are still used
outside of serialized sessions, so it doesn't make sense to mark them
"Legacy" just yet. Additionally, the keyed archiver overrides have to
be set up before any instances are unarchived, which is trickier for
these remaining model types.
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
This builds out infrastructure to fetch updated PeekInfo structs from
RingRTC on a GroupCallUpdate. There are still a bunch of TODOs to
resolve once RingRTC adds PeekInfo.
* user can add custom notification sounds from Files app (aiff, wav, or caf files)
* former OWSSound enum is now named OWSStandardSound, OWSSound turned into an alias for NSUInteger
* custom sounds get IDs based on the hash of the file name
- 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.
