Without the GroupV2Params caches, processing multiple large group
updates is extremely wasteful, decrypting the same profile keys and
UUIDs over and over again. The size of these caches has also been
*increased* to match the group size limit, or else there's no benefit
for large groups.
Other LRUCache instances are still off by default in the NSE by virtue
of the "NSE max" defaulting to 0.
If there are several group changes being returned at once,
deserializing all of them up front can lead to excessive memory use,
especially for very large groups. This commit switches to
deserializing each change as it is used, which doubles the amount of
CPU work (because we loop through the changes twice) in exchange for
only ever having one Change object graph in memory at a time. It does
also mean we can get a protobuf deserialization error a bit later in
the process if the data is ever corrupted, but that shouldn't cause
additional issues at these particular call sites.
Previously fetching outstanding challenges from the database was done
synchronously when the app was done loading, but using them was always
done from the work queue. Nothing synchronized those two, though, so
TSan flagged it as a data race.
* refactored async loading of avatar images in HomeView
* async loading avatars does not use extra DispatchWorkItems anymore
* minor code changes, added comments
Josh reported an issue where a failed outgoing reaction message would
continue to retry. This message would fail to build its proto because
the reacted message no longer exists.
If we can't build message proto, there's not really any point in
retrying the message.
Following a profile update, we need to reupload the avatar. Currently
we're uploading the avatar by writing it to a temporary file and kicking
off an NSURLSessionUploadTask.
If Class A keys aren't available, we'd fail to complete the upload. This
would remove the user's avatar from their profile.
Matthew previously stripped this down in our fork of AFNetworking; at
this point there's no benefit to it living in a separate repo and
separate target.
OWSHTTPSecurityPolicy was originally a subclass of AFSecurityPolicy
specifically for use with Signal-run services, but it already contains
the part of AFSecurityPolicy that we use elsewhere.
