DPL: do not anticipate oldestPossibleTimeframe

[ktf]

No description provided.

[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 @shahor02 this is what we discussed offline. The "earlier forwarding" PR might be anticipating the sending of the oldest possible timeframe too much, resulting in the crash you witnessed in the sync reco for some of the calibration devices. This moves makes the new behavior similar to the previous one.

[ktf]

This seems to actually not be required, as discussed. Since the earlier we send the oldest possible timeframe the better, I am keeping the current behaviour.