Make calibration scan robust against front-end communication errors

Description

This long-awaited MR aims at making robust the following calibration scans:

• DAC scan
• S-bit rate scan
• Threshold scan
• Latency scan

For the non-tracking data scan, no explicit re-tries are attempted in case of a communication error. Nevertheless, efforts went into masking the smallest part of the system for the smallest amount of time, i.e. from a full chamber during a whole scan to a single VFAT during a scan point.

For the tracking data scan, since it is known that L1A can corrupt slow-control transactions, retries are attempted when moving from one scan point to another. Communication errors during configuration are following the same rules as the software blaster: the problematic VFAT is entirely disabled.

Due to the deep implications of the changes, a very careful review is needed.

Two follow-up MR requests are anticipated. The first one is dedicated to improving the behavior of the configuration files during a bootstrap operation (e.g. installation of a new chamber). The second one is dedicated to fixing any issue/flaw discovered during in-depth testing in real case scenarios if needed. In particular, the error reporting and the possible need for re-tries.

Related Issue

How Has This Been Tested?

Help needed! 😰 There are many changes to be tested by innocent hands in many cases, on working and non-working setups.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.