DPL: check for state transition updates also in input-proxy busy loop

[ehellbar]

No description provided.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[ehellbar]

Summary of changes

1. move switchState(), hasOnlyTimers(), hasOnlyGenerated(), on_data_processing_expired(), on_transition_requested_expired() and updateStateTransition() from DataProcessingDevice.cxx to DataProcessingHelper.cxx
2. updateStateTransition(ServiceRegistryRef& ref, ProcessingPolicies const& policies) -> updateStateTransition(ServiceRegistryRef const& ref, ProcessingPolicies const& policies)
3. fix mismatches of calibration and device signpost ids
4. check for state transition updates at every 10th input channel of input-proxy busy loop

[ktf]

given you use sapling, could you split this commit in two? One for the refactoring to a different file (which most likely has no issues) and a smaller one where you only patch the output proxy. It can still be one PR, however that will allow us to quickly revert only a small commit, if needed.

[ehellbar]

yes, makes sense. Done. Originally I thought that we need the refactoring only if we use it in the input-proxy as well, so I kept it as one commit. Now it's two.

[alibuild]

Error while checking build/O2/fullCI_slc9 for 15dc591 at 2025-11-07 05:42:

No log files found

Full log here.