PROBLEM
The PDF export in InstantTranslate (when PDF via Visual is active) may run into a timeout presenting the user a "500 Server Error". The Reson is, that the Download in InstantTranslate actually triggers the Visual Export and must wait for the Visual Export-Workers to finish. Since this is wrapped in a single request it can fail with a timeout.

SOLUTION
Instead of triggering the Export from the GUI the Download/exported task should be available, when the Export is already done. This strategy should be applied to all InstantTranslate Filetypes but must be achieved for the PDF download via the visual.
The best Solution would be a Download/Export management consumed by InstantTranslate (and the main App). Maybe this could be Introduced with this Feature only for InstantTranslate? So, the Architecture and implementation must be thoroughly planned for this feature beforehand.

For InstantTranslate it is important, that if the user edits the task again through the "open task for editing" mode directly from InstantTranslate, download must be disabled while the task is open and user must see, why. When closing the task, if segments where changed (and only then) the download needs to be regenerated.

TECHNICAL CONCEPT

• Add new table LEK_instant_translate_task that holds the state & export-id created for InstantTranslate
• LEK_instant_translate_task will hold a taskId, a queuedExportId and a state (which can be "import", "export" and "ready")
• When a FileTranslation is added in InstantTranslate, an entry in that table is made with the taskId in state "import"
• InstantTranslate Listens to editor_Models_Import_Worker_SetTaskToOpen "importCompleted" event
• Triggered by this Event, The task will be exported as queued export: LEK_queued_export (no token neccessary). LEK_instant_translate_task will be updated to "export" with the queuedExportId
• The queuedExport must be changed to not clean up the files automatically for some exports (idea: add the lifetime as column in seconds to the db-model, if set to 0, file will not be deleted)
• a PDF import usually will be made via visual-review (configuration), so in that case the queued export actually is a visual export. (Hint a pdf import via visual has task-meta "visualPdfWorkfile" set)
• The cleanup of queued exports will be made via InstantTranslate (as it is currently)
• When is an task ready for download: if the task has the state "ready" in LEK_instant_translate_task. If it has the state "export" there, the state must be evaluated by fetching the related LEK_queued_export row and check for QueuedExportService::isReady. If the export is ready there, we set the state "ready" in LEK_instant_translate_task (to avoid fetching LEK_queued_export for no reason). The path of the export will be retrievable  via QueuedExportService::composeExportFilepath
• For this project it shall be anticipated, that a failed export will result in a defunct export-worker (usually the OKAPI worker), see Issue TRANSLATE-5628
• One problem will be, to evaluate a proper error in case of an defunct export: It can be assumed, that the last task-log entry for that worker represents the export-error. To get the last worker: The last worker (by starttime) with state "defunct" for the task will be it. TRANSLATE-5628 should fix the field "worker" so it is actually filled.