readout-proxy: correctly populate TimingInfo

[ktf]

No description provided.

[davidrohr]

thx, will try to test tomorrow!

[ktf]

This was all green and the errors are actually unrelated (bumped glibc on CS8). Is it ok to merge it?

[ktf]

@davidrohr @shahor02 Ok, this works. Checked on my box. There are two issues:

• TimingInfo was not getting populated in the first place.
• The message comes too early for the way the readout-proxy works, so I introduced a callback which is invoked after the processing has happened.

This means that for now we need two messages per timeframe and only the "done" one will get the correct firstTFOrbit.

[ktf]

E.g.:

[11171:raw-file-reader]: [16:57:19][INFO] Processing timeslice:3, tfCounter:3, firstTFOrbit:0, action:0
[11171:raw-file-reader]: [16:57:19][INFO] Starting new loop 3 from the beginning of data
[11171:raw-file-reader]: [16:57:19][INFO] Reading TF#3 (0 at iteration 3)
[11171:raw-file-reader]: [16:57:25][INFO] Sending 190913 parts to channel dpl-chan
[11171:raw-file-reader]: [16:57:25][INFO] Sent payload of 100170876 bytes in 190913 parts in 1 messages for TF#3 firstTForbit=1 timeStamp
=1650546674845 | Timing (total/IO): 0.5800000000000001 / 0.29000000000000103
[11171:raw-file-reader]: [16:57:25][INFO] Done processing timeslice:3, tfCounter:3, firstTFOrbit:1, action:0

[ktf]

To properly fix this we would need to move the readout-proxy to use Lifetime::OutOfBand, which then injects data at the right moment like any other input.