Move the subgraph task to the blocking thread pool

[leoyvens]

This is probably the busiest task in indexing nodes and it blocks on the DB on many of its steps. Locally I could not reliably measure whether it reduced contention, but still seems worth seeing what happens on the hosted service. Even if we can't see a change, in principle this is a correct thing to do.

Part of #937

[lutter]

Looks good in general, and I agree it's worth trying out. Just to help me understand: does this make it so that everything to do with subgraph indexing runs on the blocking pool? Are there any downsides to that?

And: how will we know that this change is an improvement once it gets put into production?

[leoyvens]

@lutter It makes it so that task, which is the driver for subgraph indexing, runs in the blocking pool. The downside is that the interaction with the reactor (to park/unpark) requires cross-thread communication, which is neglibile for us. Once tokio-rs/tokio#588 is done, there will be a more convenient way of putting tasks in a blocking pool, and then we can experiment with putting all tasks which may block in the blocking pool.

We can compare the frequency of "Possible contention in tokio threadpool" warnings to tell if it helped, which isn't very scientific but it's what we have.