The purpose of this change is to alleviate the
main source of CPU-grinding after sending a
message to a large group: about 20% of the total
time is spent decoding and re-encoding messages as
they are fetched from the DB and then updated with
info about which recipients have acknowledged
delivery.
Prior to this commit, we decrypted the payload and
then processed the message in a single rather deep
call tree that began in `processNextBatch`. There
are two completely different paths through this
tree that lead to handling a delivery receipt
because server-generated delivery receipts have
the necessary info in plaintext in the envelope
and client-generated delivery receipts have it in
the ciphertext.
The idea here is to break incoming envelope
handling into two parts.
In the first part, each envelope is decrypted and
other common activities (like handling sender key
distribution messages) are performed. A processing
request is created for each. Next, processing
requests are handled. It's easy to examine a
processing request to determine if it is a
delivery receipt, and if so, for what outgoing
message. Doing so allows the new
DeliveryReceiptContext class to cache message
fetches and combine updates to the same message.
Processing requests are grouped together so that
sequential delivery receipt requests enjoy caching
of messages and coalescing of updates into a
single fetch/decode/encode/commit. Other kinds of
envelopes are handled immediately to avoid
increasing memory pressure that caching multiple
messages could cause.
We're very close to being able to decrypt messages sent to our PNI,
but *until* that point it's best to just drop any such messages. This
should make testing easier.
These tests fulfill an expectation when a write to the database causes
the desired state to be reached. However, there may still be writes to
the database in flight, and the *next* write will *also* probably be
in the desired state, resulting in the expectation being fulfilled
again. Because this happened *after* the test finished, an exception
was thrown, the test environment terminated, and the *next* test (or
possibly a later one) was being blamed for the failure.
Fix this issue in both places where it happens by allowing multiple
fulfills, and re-enable the test that was previously getting blamed
for this.
UIDatabaseObserver orchestrates notifying views when a transaction commits.
We back UIDatabaseObserver with a DatabaseRegionObserver
DatabaseRegionObservers are not notified if the transaction contains no changes:
https://github.com/groue/GRDB.swift/blob/af0ac15/GRDB/Core/DatabaseRegionObservation.swift#L119
However the more general TransactionObservers *are* notified even if the
transaction contains no changes. Nicely, GRDB does some work to ensure this is
true even in the event of a deferred transaction. See this comment on `databaseDidCommitEmptyDeferredTransaction`
da459386a0/GRDB/Core/TransactionObserver.swift (L444)
ContactAvatarBuilder works with SignalServiceAddress
Currently this only functions with the GRDB adapter. There are other asserts
triggered in yap extensions.
