Process world state download data on a worker thread

[ajsutton]

PR description

The world state download processing was causing the netty thread to back up, resulting in other requests timing out before we pulled the response they were looking for off the netty queue.

This is a pretty minimal change to move processing of world state download onto eth worker threads. The number of threads has been increased since it's now shared between chain and world state downloads. We could alternatively have a separate world state download thread pool but that seems excessive.

[mbaxter]

There are a few other spots that could be blocking - doCancelDownload clears the queue, which could be expensive, and requestNodeData runs a for loop that calls dequeue repeatedly. Is it worth running those on the worker threads as well?

[ajsutton]

I think clearing the queue will be ok and moving it to a separate thread makes it more difficult to get all the synchronisation right. The requestNodeData is primarily called from processing responses to other requests which is ok but yeah that initial call in start should probably be on a worker thread as well.