Remove timeouts that are not proportional to the pages

[apyrgio]

The Dangerzone container currently has two types of timeouts:

dangerzone/container/dangerzone.py

Lines 27 to 31 in 56b5b98

	# timeout in seconds for any single subprocess
	DEFAULT_TIMEOUT: float = 120
	# timeout in seconds for compressing a single page of the final document
	COMPRESSION_TIMEOUT: float = 10

• DEFAULT_TIMEOUT is a timeout that applies to any command that runs in a Dangerzone container.
• COMPRESSION_TIMEOUT is a timeout that applies to a specific command (compressing a PDF) that is proportional to the number of pages in the PDF.

The second type of timeout should be our end goal. The reason is that the first type of timeout is page-agnostic, meaning that operations on large PDFs may surpass it. There are several issues that exemplify this problem:

• ps2pdf compression timeouts for large pdf files #70
• pdfunite times out on M1 Pro #314
• Error in separating document into pages , timeout 120s #306

The reason we're still stuck with the first type of timeout is that (until recently) we didn't have a way to know the number of pages of a PDF beforehand. Now that we do, we can do the following:

1. Grab the number of pages in a document as soon as we can.
   • Generally, this means after we have a PDF document we can work with.
   • This means that operations on files that are not PDFs (e.g., .docx, .xlsx) will have to use a page-agnostic timeout.
   • For large images or non-PDF documents, maybe we can have a per-MB timeout.
2. Settle on a per-page timeout that is sufficient for all of the PDF operations that we use. Currently this seems to be 10 seconds.
3. Replace all global timeouts with a pages x per page timeout.
4. Add a CLI command that will allow users to change this proportional timeout to something bigger. This should act as an escape hatch, so that users won't need to re-build the image, if they need to change it.
   • Since it's an escape hatch, it will not be visible in the UI for now. The end goal after all is to have something sensible that all users can work with.
5. Add a CI test that converts a very large PDF (e.g, 1000 pages). The rationale is that we've missed these cases, because for the time being we didn't have such tests. Bonus points if it fails in the main branch but works on our new implementation.

[deeplow]

Timeout for office documents

This may be the only thing that's out of the scope of this issue. I noticed that the there are two situations where timeouts cannot be proportional to the number of pages. This is because they happen before we have a PDF document and thus before we can even calculate its size. Images should be fine but office documents may be normally large

dangerzone/container/dangerzone.py

Lines 197 to 200 in 56b5b98

	run_command(
	args,
	error_message="Conversion to PDF with LibreOffice failed",
	timeout_message=f"Error converting document to PDF, LibreOffice timed out after {DEFAULT_TIMEOUT} seconds",

I tested converting a 500 slide document and it went past a minute on my system. I don't think libreoffice --headless provides a way to keep track of the progress of the conversion. Maybe some side-effect of the conversion (like tempfile or logs) can help us detect that. But I don't think that would be super wise.

Another way to solve this it to make it proportional document's file size or just simply remove the timeout here.

[apyrgio]

Another way to solve this it to make it proportional document's file size or just simply remove the timeout here.

I agree, that's why I suggested above that we can have a per-MB timeout. But we'll see...