PVF validation host livelock

[pepyakin]

There is a potential livelock in the PVF validation host code.

In order to trigger it the following set of conditions need to take place:

1. there is a request for preparation of a certain PVF.
2. the preparation worker process dies.
3. approximately at the same time, the pool receives a message which then leads to calling of purge_dead clean up routine.
4. this leads to a race between purge_dead and I/O error originating from a read call on the UDS socket that connects the worker and the validation host. (NOTE that the race itself is not unforeseen and was an acceptable part of the design)
5. rip message is sent back to the queue
6. the queue will react by re-adding the message back into the execution queue optionally spawning an additional worker.
7. then when the worker is spawned or freed and picks up that job the cycle starts all over.

So in order to trigger it, those things that should take place:

1. the preparation worker dies.
2. the preparation pool receives a message in the narrow time window that triggers purge_dead
3. on top of that purge_dead wins the race to the read I/O error.

The first condition may be not easy to trigger, but it is possible. Either the node itself is under heavy load (esp. memory-wise) or the attacker crafted a PVF that can lead to panics in the preparation process.

The second and the third condition seem to be very unlikely. The preparation needs to be requested just in time between the exploited worker dies and but before the kernel notified the polkadot process that the pipe is closed and the async runtime picked up that change.