Fix /tmp Filling Up Bottlenecks (server + client)

[deeplow]

The temporary (/tmp) space limitations of Qubes revealed some bottlenecks in the current architecture of Dangerzone, which is manifest themselves in large files (150+ pages). The containers version isn't as affected sync the /tmp file system has more space, but addressing this issue will improve the situation overall.

The problems

As far as I can tell, there are two main issues:

• (client) Handle RGB pages not fitting in temporary directories #526
  Lack of space in client: just a consequence of us waiting on all the RGB files to finally start reconstructing the file
• (server) Qubes: Conversion of medium-sized documents fills up /tmp #574
  Lack of space in server: even though the RGB files are deleted as soon as they are sent, the reality is that the RGB files are produced much faster than the client can consume them

I tried to illustrate some of this issues in a diagram:

[harrislapiroff]

Code to resolve this is in progress on 616-main-pymupdf (will supercede #619)

[apyrgio]

We've successfully tackled this issue (see #526 (comment)).

[deeplow]

Hurray! Glad to see this one closed 🙂