DPL: clean up leftovers from input stream after parsing a workflow

[ehellbar]

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

[ehellbar]

for certain piped workflows, when I use debug severity, there are some leftover debug log messages from destructors after the parsing, which makes the parsing fail and throw the runtime error.

E.g. there are messages from FairRoot and the CcdbApi:

[WARN] following line found  in input stream after parsing workflow: EBUG] removed RTDB container factory ContainerFactory
[WARN] following line found  in input stream after parsing workflow: [DEBUG] Cleaning up semaphore registry with count 0
[WARN] following line found  in input stream after parsing workflow: [DEBUG] removed RTDB container factory MagFieldContFact
[WARN] following line found  in input stream after parsing workflow: [DEBUG] removed RTDB container factory FairBaseContFact

[ktf]

Why not using a signpost, so that we actually can turn it on if needed?

[ehellbar]

great idea. It just took me a while to figure out that I have to enable the workflow_importer signposts via the DPL_DRIVER_SIGNPOSTS variable 🤦‍♂️