Strengthens validation requirements for group avatars a user sets. Also,
checks these requirements on avatars we receive.
Introduces a data migration to drop any large group avatars.
This fixes an issue some users were reporting of jetsaming in the share
extension. All group avatars are stored in-memory on TSGroupModel.
Until we have a better strategy for memory management here, we'll want
to keep group avatars small.
OWSAccountIdFinder is no longer used for dependency injection in
SignalMetadataKit, so there's no need to allocate empty NSObjects just
to call the methods.
No functionality change.
This puts up the facade for the future we'll eventually want: the
database contains serialized protobuf data, not AxolotlKit
SessionRecord objects. This also allows us to transparently handle
fetches when the database can contain *either* SessionRecords or
serialized data---we only need to check which we have.
This was the last part of SignalServiceKit that poked inside
AxolotlKit's SessionRecord, and SignalClient doesn't currently expose
the same information. However, it was only being used as a heuristic
for merging phone number and UUID contacts when you already had a
session with each, and this just won't happen anymore except in rare
circumstances. (Specifically, all messages will have UUIDs, so a UUID
contact is always more up to date.)
For now, this means some extra translation between AxolotlKit and
SignalClient types, but it helps pave the way for lazily migrating the
database to store protobuf-serialized records instead of
NSCoding-archived ones.
Doing this correctly means going "back" to proto2 for SessionRecords,
because we need to distinguish between "0" and "absent" in the
serialized protobuf data. (Note that we can do this independently of
SignalClient properly making this distinction because the proto3
implementation we're using, prost, will omit scalar proto3 fields
whose values match their defaults.)
By including eraId in GroupCallUpdate messages, we're able to identify
separate group calls after the fact. Each unique eraId will result in a
new entry in the database, even if the group call has since ended.
