Larger play thread pool, async fossil client

[fm3]

• Remove usages of ExecutionContext.global. Using that discouraged because there are no limits to how many threads it spawns. Before this PR, we randomly used it whereever it was too hard to inject the play execution context.
• Adds a sensible config for the play execution context. Before this PR, the default config was used, which yielded way too few threads for the amount of blocking operations we have.
• Adapts most of the fossildb gprc client to async and adapts its error handling accordingly. With one exception, which is getMultipleKeys, because that is used in Iterators, which are harder to rewrite to async (this may be a future optimization)

TODO

• get rid of global execution contest
• adapt akka config for some more threads
  • also in datastore + tracingstore
• go for more async io usages
  • async fossil client
    • adapt health check
    • adapt get request
    • adapt other requests
    • error handling (exceptions are thrown inside the future?)

URL of deployed dev instance (used for testing):

• https://threadpools.webknossos.xyz

Steps to test:

• Test that data loading for remote datasets still works
• Test that annotating (save, reload, download) still works
• To actually test the improvements in parallelism, I used the test route added in 4c96ce4 – sending a lot of parallel requests to /tracings/test showed in the logging how the requests were answered in parallel

Issues:

• fixes Optimize ThreadPool usage, make more use of async IO #7140

---

• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases
• Needs datastore update after deployment

[fm3]

the whole file was unused

[fm3]

Upgrade not really needed for this, but shouldn’t hurt (I added it while debugging something which turned out to be caused elsewhere)