Fix starting runs

[wilko77]

It all started with this strange failure in a clkhash test:

State: queued
Stage (1/3): waiting for CLKs
Progress: 100.00%
State: queued
Stage (1/3): waiting for CLKs
Progress: 100.00%
State: queued
Stage (2/3): compute similarity scores
State: running
Stage (3/3): compute output
State: running
Stage (4/3): there is no description for this stage

It turns out, that the entity service is naughty.

The problem is around the detection of the race condition to start a run twice.
The idea is that a run's state is set to created after creation, and only once all data provider have uploaded the necessary clks, the run state gets promoted to queued and, consequently, the run execution gets started.

However, some naughty code in views/run/list.py:post did some premature clk checking and run state changing. After all that, it would still call the check_for_executable_runs task, which will then do exactly the same again.
Now, as we previously "fixed" the get_created_runs_and_queue by allowing to return runs that are either created OR queued, together with the fact that check_for_executable_runs can be called twice almost in parallel, led to double queuing of the run and double stage progressing.

To stop all this nonsense, I propose to not include run logic in the views of ngnix. If we always call the same task as entrypoint (check_for_executable_runs), it will, most likely, keep as saner for longer. Hopefully.

[gusmith]

Nicely spotted.
Only things to close this PR is to update the changelog.

[gusmith]

👍

[gusmith]

Need to add this dependency update in the changelog.