Fix hanging when starting over 512 subgraphs

[leoyvens]

This issue was introduced when upgrading to tokio 1.0, the #[tokio::main] syntax changed and the number of blocking threads was inadvertently lowered from 2000 to the default 512. I was able to reproduce the issue locally. This fixes the root cause which is the incorrect use of the blocking thread pool. At least in the critical locations, we still use it incorrectly in others, #905 tracks getting this right in all places.

There are at least two ways we where using the blocking thread pool incorrectly:

• The code path to start a subgraph had a few nested calls to spawn_blocking. This leads to a "double dip" deadlock, the nested calls are waiting on the callers to release a blocking threads, but the callers are of course waiting on the nested call to complete.
• We were using spawn_blocking for the task that calls run_subgraph. Tasks that run indeterminately should not be put on the blocking thread pool, because that could exhaust the available threads. Ideally we'd make it so that run_subgraph doesn't do blocking calls, but the quick fix is to use an OS thread. I added graph::spawn_thread to make this convenient.

[lutter]

I think this is ok. In this commit I had to move start_subgraph_deployment to the same thread that does run_subgraph since, with copying, start_subgraph_deployment can take hours and would otherwise block the instance manager. (There's nothing to do for this PR, just an FYI)

[leoyvens]

Good thing it is in a blocking task then! Ideally it would use something like with_conn but it didn't seem so straightforward to refactor it, so that's left for another day.