Make storing a run not wait until storage is complete

[whisperity]

With the added statelessness and the complexity of parsing a report ZIP it should be done so that this parsing does not hang one thread of the web server pool, and neither does keep a socket open. The user could time out while the server is generating the return value of massStoreRun, which could have unforeseen consequences.

Ideas:

1. Make the Webserver process pooled instead of thread pool. This could be a big help in alleviating for the GIL.
2. massStoreRun should start a direct, detached subprocess which is internal to the server host. This subprocess could independently handle the parsing and storing of the result ZIP. This way the user's connection is closed once the ZIP is dispatched, and instead of waiting for the reply in the same connection, it could be made so that the client actively pings the server to tell them when the build is successfully stored, or failed. This would require a change on the API and handling, and also to introduce a little bit of interprocess communication, or saving intermittent state data to the database (presumably into a new table which is recommended to be in the MEMORY backend).

[gyorb]

I was thinking about this setup for some time. I think we should check the features by Celery.

[whisperity]

>mfw this has been an issue since 2018 and not just 2022 like originally thought???

Okay, while not exactly matching the design that was proposed here, #3672 is a better thought-out version of this issue without the need for GIL changes, detached subprocesses, etc.

From the user's PoV, we will simulate the blocking wait internally (or the user can just go --detach in order not to wait for anything).