pvf: fix the deadlock when any of the channels get at capacity

[pepyakin]

The PVF host is designed to avoid spawning tasks to minimize knowledge
of outer code. Using async_std::task::spawn (or Tokio's counterpart)
deemed unacceptable, SpawnNamed undesirable. Instead there is only one
task returned that is spawned by the candidate-validation subsystem.
The tasks from the sub-components are polled by that root task.

However, the way the tasks are bundled was incorrect. There was a giant
select that was polling those tasks. Particularly, that implies that as soon as
one of the arms of that select goes into await those sub-tasks stop
getting polled. This is a recipe for a deadlock which indeed happened
here.

Specifically, the deadlock happened during sending messages to the
execute queue by calling
send_execute.
When the channel to the queue reaches the capacity, the control flow is
suspended until the queue handles those messages. Since this code is
essentially reached from one of the select
arms,
the queue won't be given the control and thus no further progress can be
made.

This problem is solved by bundling the tasks one level higher instead,
by selecting over those long-running tasks.

We also stop treating returning from those long-running tasks as error
conditions, since that can happen during legit shutdown.

[rphmeier]

@vstakhov if you find it correct, please merge

[vstakhov]

bot merge

[drahnr]

nit: We should maintain logs here which one terminated.

[pepyakin]

Which severity you reckon?

[drahnr]

error! I'd say, this should really never happen

[pepyakin]

The reason why I removed never!s is that those paths can theoretically be hit during normal shutdown.