[skip ci] editoast: fix train simulation batch endpoint

[flomonster]

[!NOTE] We are running both endpoints simultaneously. This means that the times observed without cache are distorted. It would be best if you looked at the max of both endpoints.

1) Initial situation

[!IMPORTANT] ❌ The health endpoint is slow when calling these endpoints.

No cache

Project path: 30s Summary: 25s

Hit Cache

Project path: 4s Summary: 1.48s

2) Disable parallelization

[!IMPORTANT] ✅ The health endpoint is fast when calling these endpoints.

No cache

Project path: 113s :turtle: Summary: 4s

Hit Cache

Project path: 5s Summary: 3.8s

3) Create a new runtime

[!IMPORTANT] ❌ The health endpoint is slow when calling these endpoints.s.

No cache

Project path: ? Summary: ?

Hit Cache

Project path: 6s Summary: 2.63s

[flomonster]

The health endpoint takes time to respond not because of the number of tasks scheduled by tokio but the number of queries sent to postgres (and maybe redis too).

I will make a new PR that reduces the number of calls made by the train-simulation-batch function.