Latency monitoring improvements

[MRiganSUSX]

New latency monitoring for trigger is introduced with #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

[ArturSztuc]

I assigned this to v5.x.x (not v5.3.0): Let's get the replay working first, and then we can test different updates/solutions for the latency monitoring.

Prescaling would be a good feature for the TP latency monitoring, depending on the current overheads.

I would also add "removing the difference between object in & object out" plot, as it can be very misleading.

[ArturSztuc]

Still in v5.x.x. @MRiganSUSX what's the current status of the latency measurements in the replay application since it has been rewritten?