Our envelopes go through a lot of transformations during processing:
0. If using REST, JSON delivered by the server is converted to
SSKProtoEnvelope (MessageFetcherJob.buildEnvelope(messageDict:))
1a. If using REST, envelopes are serialized and enqueued for individual
jobs (MessageFetcherJob.fetchMessagesViaRest())
1b. If using the web socket, the message is deserialized from protobuf
(MessageProcessor.processEncryptedEnvelopeData(...))
2. If the envelope uses sealed sender, the sender is written into
a new proto and reserialized
(OWSMessageDecryptor.decryptUnidentifiedSenderEnvelope(...))
3. The serialized envelope is deserialized *again* for preprocessing,
GV2 discard mode checking, and (potentially) actual processing.
(MessageProcessor.processEnvelope(_:transaction:))
4. If the envelope is delayed, it'll be deserialized when it's finally
processed
(IncomingGroupsV2MessageJob.envelope)
This commit improves the situation by
- skipping the serialization in step #1a
- skipping the serialization in step #2
- reusing the SSKProtoEnvelope from decryption in message processing,
avoiding the deserialization in step #3
- potentially serializing in step #4 if there's no up-to-date
serialized data (either because the envelope was modified, or
because it came from REST and we never had it in the first place)
Note that IncomingGroupsV2MessageJob is persisted across transactions
in the database, so it needs the envelope to be serialized.
7ba2a8ee2d