[Feature]: Introduce thread pinning into the FSM sequence for daqsystemtest configs.

Description

Introduce thread pinning into the FSM sequence for daqsystemtest configs.

Furthermore, the cpupin file referenced is from an readoutlibs version on cvmfs which is now archived. This should point to datahandlinglibs. The cpu pinning file itself out of date and would benefit from updating.

Potential impact radius

Small/Isolated

Reason for change

Currently, the fsm transitions in the daqsystemtest configs do not use the thread pinning fsm action, thus this aspect of the readout is not exercised at all during any tests.

Suggested implementations

see this branch: https://github.com/DUNE-DAQ/daqsystemtest/tree/sbhuller/thread-pinning
for how the thread pinning can be included in the fsm configuration.

Testing suggestions

1. run the local 1x1 config and bring the system upto conf
2. check the logs of the root controller logs --name root-controller and check for messages that indicate the pinning was successfully applied, such as ### CPU affinity applied!

For more detailed checks, the pinning file itself needs to be updated to match the thread names of the readout applications defined by the test configs.

Anything else?

There is a PR which does update the example pinning file in datahandlinglibs: https://github.com/DUNE-DAQ/datahandlinglibs/pull/126

This will need to be propagated to the daqsystemtest configs (though I am unsure this works given the current path points to a released software version, which this instance of datahandlinglibs is not right at time of making the issue.)

Compare the daqsystemtest FSM configuration with the sbhuller/thread-pinning branch, then trace the referenced cpupin file and the datahandlinglibs PR #126. Run the local 1x1 configuration up to conf and inspect root-controller logs for a CPU-affinity-applied message. Done means the FSM exercises thread pinning and the pinning file matches the readout application thread names.