feat: async. HTTP communication in tesseract REST API

[linusseelinger]

Relevant issue or PR

N/A

Description of changes

The Current REST API makes one sync. HTTP request, whose response may return after hours in case of long-running tasks (e.g. simulations).
Here we introduce new endpoints for asynchronous handling of long-running simulators, specifically in a long-polling fashion:
The client new requests a new task execution and immediately receives a task ID. The client may then repeatedly request to retrieve the task's output; said requests return after a short blocking timeout while the task is still running, but return immediately once the task is done.

Task execution is offloaded to a ProcessPoolExecutor. Worker processes need to initialize the tesseract API themselves, since they don't inherit locally constructed endpoints and schemas from the main process.

As it stands, this is intended as a draft to see if it meets the required needs. Once that is confirmed, there are a few technical points to look into:

• Honor the user-specified number of workers.
• Possibly avoid redundant checking when serializing/deserializing inputs and outputs when passing between worker and main process.
• Either accept or avoid the changes in tesseract_core/runtime/schema_generation.py.
• Attaching schemas to endpoint functions works (and is actually kind of elegant here) but probably not good practice. Any cleaner approach?
• General clean-up iteration.

Testing done

Simple local testing done
TODO: Ensure CI covers asynchronous AND synchronous endpoints

[PasteurBot]

CLA signatures confirmed

All contributors have signed the Contributor License Agreement.
_{Posted by the CLA Assistant Lite bot.}

[linusseelinger]

@PasteurBot I have read the CLA Document and I hereby sign the CLA

[jpbrodrick89]

@linusseelinger let me know if the validator stuff becomes a bottleneck/blocker at an point, I have a draft PR (not pushed) for some of the validation stuff (mainly (co)tangent vectors) that I de-prioritised, not sure whether this is relevant or not.

[linusseelinger]

Nice @jpbrodrick89 :) Honestly, at this point, I have no idea how performance relevant the redundant validation is here. Maybe we can work around that all together (seems unlikely though); if no, would be great to see your approach!