The TSGroupMember table is updated after every inserted interaction. It
asserts that the sender of the interaction is in the group membership.
Before, our tests would construct groups with mock membership and then
construct outgoing messages with the local address as the sender. This
would fail this new requirement.
The fix is to make sure that the local address is in the test group
membership if we'd like to "send" any messages.
Date+SSKTest has a suite of tests that checks parsing of HTTP and
IOS8601 dates directly
NSURLSessionDataTask+OWS_HTTPTest validates that the Retry-After parsing
of NSHTTPURLResponse works as expected
Also, this change renames the NSURLSessionDataTask extension header to
something more generally appropriate
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.
This commit adds two new synchronization utilities:
- Unfair locks: This adds an Objective-C wrapper around os_unfair_lock
to help bridge it to Swift. (Swift's handling of the underlying C
struct can lead to surprising TSan failures). This will be useful as a
simple, performant lock in cases where fairness is not a concern.
- Shared serial queues: Private serial queues that are untargeted will
target the global concurrent queues. Sometimes this is what we want,
especially for potentially long-running work items. But for cases
where work items are brief private serial queues risk spinning up a
new thread.
For private queues where the individual work items are brief and there
isn't a more appropriate queue to target, the shared serial queues
are a potential candidate.
This change also introduces tests for these new utilities and some QoS
management helper methods.
