Latency monitoring improvements

New latency monitoring for trigger is introduced with https://github.com/DUNE-DAQ/trigger/pull/342.

Some issues:

• currently updating latency for each TX object, which for TPs is more often than reasonably useful and adds an overhead
• in cases where the rates are high, we are effectively comparing different objects when we publish our latency_in and latency_out. The latency out will be the latest (TX+1) object that was made while the latency in is the newest incoming TX object. We report the values at the same time, but they do not refer to the same object anymore (different base of comparison). While this is still useful latency reporting, it can produce 'weird' cases for the online monitoring.

possible improvements:

• using condition variables for updating
• adding some kind of prescaling / a rate check for the updates

Start by reviewing pull request #342 and the latency-monitoring implementation it introduced. Trace how latency_in and latency_out are updated for TX objects, then evaluate condition-variable updates or prescaling/rate checks; done means reducing update overhead and ensuring published values have a consistent object relationship.