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.
When Data is put into an NSCache it gets converted to an NSData, which
is a CFData underneath. CFData's hash function only looks at a prefix
of the data, and the secret params were taking up a good chunk of that
prefix, leading to hash collisions. By putting more variable data
first, we get better hashes *and* exit memcmp faster in the case of a
collision.
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.
SenderKey requires that building a message is agnostic from a single
recipient. This makes the recipient argument when building an outgoing
message optional.
Currently this is used to determine if a profile key should be appended
to the message. A different solution will be required for SenderKey
messages.
