## Test Workflows

### FLP Qualification:

Initial mockup for a generic FLP workflow

This is currently just an refactoring of the o2ParalleWorkflow test,
with a bit more comments to indicate what the various parts do.

There are two layers of processing, one which is parallel in the
subspecification (i.e. in the channels), the second one which is
parallel in time, i.e. if the subtimeframe processing requires extra
cores and longer latency in order to complete. The number of processor
for the two layers can be controlled via the command line options.

The connections to Readout and DataDistribution are not actually there
yet, but they come next.

Synopsis: flpQualification [options]

Relevant options:

* --2-layer-jobs <n> : number of data parallel workers in the first processing
  layer
* --3-layer-pipelining <m> : numer of time pipelined workers in the second processing
  layer.
* --input-type <type>: where <type> can be `readout' or `stfb'. The former will assume messages
  do not have a O2 Data Model structure and it will enumerate each message with a custom DataHeader /
  DataProcessingHeader. The latter will assume that the messages already come in proper (header, payload)
  pairs and that the header already has at least a DataHeader and a DataProcessingHeader in it.

Readout proxy channel configuration can be done by passing the option as it
follows:

   --readout-proxy '--channel-config "name=readout-proxy,type=pair,method=connect,transport=shmem,address=ipc:///tmp/readout-pipe-0,rateLogging=1"'

These must match appropriately the configuration of `readout.exe`.