1) Move contact URI, contact photo URI, and custom label
into recipient database, so there are no longer any
contact DB queries during Recipient object loading.
2) Use a SoftHashMap so that any referenced Recipient objects
can't get kicked out of the cache.
3) Don't load Recipient objects through the provider during sync.
This was a super expensive thing to do, and blew up the cache.
4) Only apply changes to Recipient objects during sync if they
are in the cache. Otherwise, there should be no outstanding
references, and the changes are fine going exclusively to
the DB.
Expiring message timers could end up leaking references and
executing work even after their conversation item was no longer
visible
Maybe fixes#6898
// FREEBIE
This was a holdover from Signal's origins as a pure SMS app.
It causes problems, depends on undefined device specific behavior,
and should no longer be necessary now that we have all the
information we need to E164 all numbers.
// FREEBIE
1) Remove all our PDU code and switch to the PDU code from the
klinker library
2) Switch to using the system Lollipop MMS library by default,
and falling back to our own custom library if that fails.
3) Format SMIL differently, using code from klinker instead of
what we've pieced together.
4) Pull per-carrier MMS media constraints from the XML config
files in the klinker library, instead of hardcoding it at 280kb.
Hopefully this is an improvement, but given that MMS is involved,
it will probably make things worse instead.
1) QuickCamera logic moved into CameraView
2) The strategies for texture vs. surface view were too complex
with no observed gain. Better to remove and have to re-add
if necessary than assume it to be necessary.
3) Drop CWAC-Camera dependency - the device profiles weren't being
used very much and even that is deprecated so we'd be left on
our own with new hardware. Not worth it.
4) Selfies first.
5) Layout/orientation mathy logic from CWAC moved into CameraUtils,
with the hopes that most of it might be further simplified or
rendered unnecessary in the future.
Closes#4326
// FREEBIE
1) On the push side, this message is a flag in PushMessageContent.
Any secure message with that flag will terminate the current
sessin.
2) On the SMS side, there is an "end session" wire type and
the convention that a message with this wire type must be
secure and contain the string "TERMINATE."
