In most cases when working with a ConversationItem we already have a
write transaction, but sometimes we don't. In this case, we know you
can only be blocked in a conversation if there's history in it (at
least as far as the local device knows), and so we can ignore any
threads that don't exist.
Randall hit an issue where his device would take a few seconds to start
up. His logs indicate that his device is spending time running
LaunchJobs.
The first change here is to make sure we explicitly set the launch job
work at an ultra-high priority. This is okay, since we don't actually
present UI until after we finish these jobs. Running this work at
UserInteractive is appropriate since it quite literally prevents the
user from interacting with the app. There's also no other time-sensitive
UI work we need to be doing (like running animations) that we could be
contending with.
The second change is to add a bit more logging that allows us to monitor
the amount of work these jobs are doing. This will allow us to see if
these jobs are performing an excessive amount of work.
Finally, I moved these LaunchJobs to Swift. Mostly because the ObjC
implementations were block based. The additional code was going to
indent things further and our linter aggressiely indents blocks to begin
with. Moving this to Swift is much more readable.
In some of our forwarding controllers, we compute
attachmentApprovalMentionableAddresses on the fly by opening a read
transaction and fetching the group membership. This leads to a
re-enterant database transaction.
Instead, on an update to the selected thread list, we'll populate our
candidate addresses. That way the cached candidate list can be accessed
without a separate transaction.
