DPL: oldest possible timeframe triggered CompletionPolicy

[ktf]

This will trigger the processing whenever a given slot will not receive data
anymore in virtue of its timeslice being past the oldest possible timeframe.

[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

[ktf]

@ehellbar @davidrohr @shahor02 as we discussed at some point. This should allow us to wait for wildcarded inputs to be completed (i.e. no more data in that time slice possible) before running their consumption callback.

This should allow us to fix the issue with the new forwarding in a number of places which were relaying on the forwarding device to accumulate data and send it all together.

@ehellbar I am writing a test / example for this, however if you could try it out in parallel with your QC device, it would be great.

[davidrohr]

Hi, thx, this makes a lot of sense to me. It should fix a couple of issues in the future, and I think in principle we should use this policy by default.

I have one request though: Could we add an option, or have a modified alternative version of this policy, which enables to have an orderCheck, like here:

AliceO2/Detectors/TPC/workflow/readers/include/TPCReaderWorkflow/TPCSectorCompletionPolicy.h

Line 196 in 2d96089

if (retVal != framework::CompletionPolicy::CompletionOp::Wait && orderCheck && *orderCheck && **orderCheck) {

Also, a bit related but different, we have the consumeWhenAllOrdered policy, which simply enforces a strict monotonic ordering of the timeslice id. I think we should provide the same for the oldestPossible completion policy, so that we can move over the consumeWhenAll stuff to the new one.

[ktf]

@davidrohr as discussed offline, I fully agree there must be some replacement also for the ordered consuming. I will merge this (so that @ehellbar can fix the QC task which was breaking) and then I can extend the feature (including the callback you asked for).

Concerning making it default, I am not sure it's a good idea because it potentially introduces latencies if the oldest possible timeframe information gets throttled.