feat: schedule scan based on queue events

[csmig]

Resolves #117

Alternative approach to #127 that:

• schedules the next scan with a delay relative to the last worker of the current processing pipeline.
• avoids non-productive invocations of startScanner() by only scheduling when workers are finished

[cd-rite]

I think we need to remove the call to startScanner() on line 367 in onAlarmLowered()
(Or rather, make it a call to testScheduleNextScan() instead)

[csmig]

Agree that startScanner() should not be called on alarmLowered. Disagree that testScheduleNextScan() is the best replacement. I think scan scheduling should not be directly modified in alarm handling at all.

Instead, I've updated the alarm handlers to pause parseQueue and cargoQueue on alarmRaised and resume them on alarmLowered. This has the effect of stopping work when an alarm condition occurs and resuming work when and if the alarm condition is resolved. It indirectly affects scan scheduling since the next scan is only scheduled when both queues have no work remaining.

The alarm handling in this PR is a transitional implementation because overall alarm handling code is to be addressed while working #121 . I expect to be moving alarm handling code into the individual queue modules since there is common behavior in both scan and events mode.

[sonarqubecloud]

Quality Gate passed for 'NUWCDIVNPT_stigman-watcher'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud