Messages should be downloaded asynchronously on startup

[kb100]

• I have searched open and closed issues for duplicates
• I promise this is not a duplicate of Eliminate loading screen, load new messages in the background #1442.
• I promise this is not a duplicate of Linux: Message download speed is slow #3172

Bug Description

Initial startup is blocked until all new messages are downloaded and decrypted. I've finished reading through the very lengthy discussion about related issues in the previously mentioned threads. I understand that messages must be downloaded and decrypted in order due to the way the protocol works. The issue here that I have is that this is done in a suboptimal serial fashion. As mentioned in #1442, "... download, decryption, updating local state, and updating UI (the last three are done in serial)" (emphasis mine).

Optimally, the GUI should never ever be locked (queue and mark outgoing messages as "queued to send" until synced if necessary). At the very least read-only operations should never ever be locked. If need be, completely gray out the send button until conversations are fully synced, but the user should be able to view all messages that HAVE already been downloaded and decrypted.

Steps to Reproduce

1. Send a bunch of Signal messages to/from phone.
2. Open Signal Desktop
3. Observe "Loading messages ..." until all messages are downloaded and decrypted.

Actual Result:

The GUI waits for all messages to be "loaded" (all messages downloaded and decrypted) until displaying any new or old messages. This issue is exacerbated by another issue, #3172, namely that sometimes these messages are taking minutes or hours to download.

Expected Result:

The app should start and show already downloaded and decrypted messages immediately, with new messages popping into view as they are downloaded and decrypted asynchronously.

Platform Info

Signal Version: v1.24.1

Operating System: Debian Sid

Linked Device Version: 4.40.4

Link to Debug Log

https://debuglogs.org/8a93ed298c40206bb09bab8932bd662063c61664fde66736373aa2c9a7b293a6

[scottnonnenberg-signal]

How is this not a duplicate of #1442?

[kb100]

The issue is that the process should be done in parallel as much as possible.

Edit: Note the process appears to already be implemented in a different scenario, when the app is already open but disconnected from the internet, then it reconnects after a day of messages have been sent. Nothing freezes and messages just pop into view as they are downloaded and processed.

[scottnonnenberg-signal]

This is definitely a duplicate of #1442, which is about background loading. This is about background loading. Closing in favor of it.