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
Fixes a bug where we can race talking to callservicesd when starting our
first call. More detailed analysis of logs in IOS-1345 but briefly:
1. We construct a CXProvider with a maxCallGroup config of 1.
\- XPC to callservicesd
2. We start a call.
\- XPC to callservicesd
3. callservicesd processes the startCall message first. Sees we don't
have a configuration set up. Assumes maxCallGroup config value of 0.
Fails to start the call with error code: .maximumCallGroupsReached
4. callservicesd processes the configuration update and now we have a
maximumCallGroups of 1.
By delaying all of our CXProvider requests until after we receive a
delegate callback that -providerDidBegin:, we should be able to order
our requests in a way CallKit expects.
- 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
