The recent Promise changes have changed this behavior. Before, we could
assume that each promise closure was run in an independent context. Now,
with the perf improvements with `asyncIfNecessary`, the guarantee may
not always hold.
In this case, the lock acquired outside of the promise chain continues
to be held inside of the promise chain.
While running some perf tests on database queries, I was building
against TESTABLE_RELEASE to have things built with optimizations.
I saw some weird behavior:
- Share extension would crash
- No logs would be recorded
I went through and cleaned up some things that appeared incorrect with
how we handled TESTABLE_RELEASE
- First, we should skip fetching prekeys for transient messages in our
advisory call to -ensureSessionsForMessageSend:ignoreErrors:. We
already skip transient messages in our prekey fetch where errors *do*
matter, so this additional check should be able to skip the prekey
fetch as well.
- OWSOutgoingReceiptManager should stop trying to send receipts to
recipients that are untrusted. This just burns through prekey fetches
for sends that we know will fail anyway.
- SafetyNumberConfirmationSheet should handle marking a recipient as
trusted. Callers are hit or miss on whether they actually update the
verification state.
- These fixes also happen to make SafetyNumberConfirmationSheet
presentation a bit more reliable. Before, multiple confirmation sheets
might flash in quick succession. This seems to fix that
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.
Removed the extra -loadSessionIfExists method. I was concerned that we
might need to perform SignalRecipient lookups and updates in certain
cases. Nora assured me that it should be safe to always call the
read-only OWSAccountIdFinder.accountId instead of
OWSAccountIdFinder.ensureAccountId. If we have an entry in the session
store, it must have already an entry in the SignalRecipients database.
In other words, if we fail to fetch an accountId from the
SignalRecipients table, then we know there's never going to be a session
record in the session store.
