Store the returned value and check that we have what we
wanted.

https://docs.python.org/3/library/multiprocessing.html?highlight=qsize

The BEAT computation being fully asynchronous, the client does
not expect immediate reply to its requests. Therefor this
warning is misleading.

Unlike the Majordomo ZMQ example, we have "single" workers with work
assigned and possible actions taken on arrival/departure. Therefore
the purge should check the whole list to ensure that everything is
done with respect to the status of the worker.

This implements a new paradigm for the process nodes
communication. Based on the ZMQ Majordomo protocol,
its goal is to improve reliability of the setup.

Currently only the status of the main algorithm container
was taken into account to gather the stderr output of all
other containers. This patch changes this so that if
something fails but the main containers ends successfully
the other containers output can still be analysed.

Not all tests were checking for None which might happen
for reason outside of tests error.

These two algorithm allow for better testing of a complete
experiment with a database used for input of both loop and
loop user algorithm.

It was already not used when stream is set to false however in
more recent versions of the python docker bindings, an error is
raised if stream is set to false and and decode to true.

Now the request and answer fields are properly defined.

In fact, v3 adds two new block types that are clearly defined.
So either the algorithm matches v2 type blocks or one of the loop
or loop user block from v3. The schema now uses better defined
constraints.

This moves out common definitions in a separate file. This
patch also updates the execution schema to reflect that.