improve performance for many submissions per source

[redshiftzero]

On first start of the client, we add widgets for each item in the conversation view when we click on the source for the first time. If there are thousands of messages/files/replies per source, there will be a delay / the UI will be blocked as found with the SourceList in #846.

We should implement a similar fix as #944 to improve performance when adding widgets to the ConversationView.

[eloquence]

For the 4/2-4/15 sprint, we'll aim to at least test in the "100 widgets per source" range, maybe with different combinations of messages/replies/documents. Would be good to have an agreed upon process for generating and using this dataset in a dev or staging env, per ongoing discussion in freedomofpress/securedrop#5186

[eloquence]

Per #1049 (comment) the client seems to be responsive in scenarios of up to a thousand or so messages/replies/submissions. This may not be a useful target for further optimization unless/until we see evidence that even larger source collections plausibly occur in the real world.

[sssoleileraaa]

started a wiki page to track scalability and performance requirements and test results (it'll need more attention when we make time for this in the future 🔮): https://github.com/freedomofpress/securedrop-client/wiki/Scalability-&-Performance

[zenmonkeykstop]

Potentially related to #1476