DPL: Fix orderedCompletionPolicy getting stuck when oldestPossibleTimeslice message jumps by > 1 at once, and any but the last TF in the jump range is missing

[davidrohr]

This should fix https://its.cern.ch/jira/browse/O2-4777

The problem is that when 2 oldestPossibleTimeframe updates are received together, they seem to be coalesced, so they can jump by 2 (or more).
If the first TF of these (or any TF in the jump range but the last) is missing, the consumeWhenOrdered completion policy needs an updated nextTimeFrame, to know that this TF is missing. This is done within the async queue. However, if the jump is > 1, the async queue runs only when the processing has reached the end of the jump range, which creates a deadlock if a TF in the jump range is not missing, since that would still need to be processed, which is blocked by the completion policy due to the lacking async queue update.

This PR splits the async queue task in two, and runs the decongestionService.nextTimeSlice update earlier, already when the currently agreed oldestPossibleOutput.timeslice.value timeslice has been reached, unlocking the completionPolicy.

[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-apass
async-2023-pp-apass1
async-2022-pp-apass6-2023-PbPb-apass2
async-2022-pp-apass4
async-mc
async-data

[martenole]

Thanks a lot! Shall I wait for the fullCI to finish and merge afterwards?

[davidrohr]

Yes, you can merge once it is green.