iOS keeps track of the last-used skin tone modifiers for every
reaction emoji you use. Before reactions were customizable, this
applied to the default set of reactions as well: if you went into the
full picker to select a light-skinned thumbs-up, the short picker
would also have a light-skinned thumbs-up from then on, and if you
changed to dark skin or back to "default" (yellow in our font), the
short picker would be updated again.
However, this is *not* how the customized reactions sync'd through
storage service work; those have skin tone modifiers "baked in", so to
speak. These reactions weren't being treated as valid because they
weren't "base" emoji that could have a skin tone applied to them.
This PR changes things so that there are now two possible states:
- You have never customized your reactions on any platform. In this
case, skin tones continue to follow your most recent choice for that
emoji from the full picker.
- You *have* customized your reactions, in which case it's assumed
they already have the skin tones you want. This even allows you to
have multiple reactions in your default set with the same base emoji
but different skin tones.
Further commits will remove the special nature of the first state.
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.
