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.
RingRTC will now vend the urgency of an incoming opaque call message. We
can use this to determine whether or not we want the NSE to wake the
main app.
- Fetch mp4s from Giphy for showing previews
- Fetch mp4s from Giphy for sending (behind featuree flag)
- A new flag on attachments to tag a video as "looping media"
- Videos tagged with this flag will be shown on repeat
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.
Updates the proto definition to add a preview description and date
field. Date and description metadata from fetched content will be sent
over the wire. We can't render it locally yet, but at least this will
allow supporting recipients to display the content.
Also, made some minor changes to HTMLMetadata to better handle article
publish/modified date tags.
Also, re-run protobuf generation with swift-protobuf-1.8.0 to reduce a
bunch of diff noise. If we decide to migrate, we should do that in a
separate commit.