Peter M. Groen / openbr

Avoid a deadlock related to using stream inside distribute transforms

Start the individual project jobs in distribute as qrunnables rather than
through qtconcurrent::run. This is necessary since run does not allow us to
assign a priority to a task. Run the distribute tasks with a lower priority
than stream tasks.
This prevents a deadlock where a thread in stream::projectUpdate would try to
start a job and wait for it to finish, but in the meantime a distribute job
would use up the thread the stream thread released. Due to the use of
TimeVaryingTransformWrapper in distribute, stream transforms are a limited
resource, and the previously discussed situation would cause a deadlock where
stream transforms (in stream::projectUpdate) were waiting for their job to
finish, but the job never started because distribute transform threads were in
resource waiting for stream transforms to become available.

The current implementation has some important drawbacks. Not using
qtconcurrent::run means we cannot use the QFutureSynchronizer API to wait for
threads to finish. I am (temporarily) starting FakeMain in (in br) on a
local thread pool, and in distribute waiting for the complete global thread
pool to become available (this would be a self-blocking wait without starting
FakeMain in a different thread pool).

This is quite restrictive, we cannot currently ever nest distribute transforms
for example.

Also, using priority in this way is not general, nesting a distribute transform
inside a stream is infeasible under this scheme (well it already wouldn't work
due to the previously discussed problem, but this issue is a little more
persistent).