Set default DCA in case of propagate call fail

[ddobrigk]

@shahor02: I have realized that a large number of analysis tasks make use of propagateToDCA calls but don't check the main true/false return value of the call. These tasks then proceed to use the DCA stored either via something like a std::array or o2::dataformats::dca, and in case of a propagation failure, the first option results in undefined behaviour (in case the user did not initialize the floats) and the second results in a fixed value of 0.0f (initialized in DCA.h).

In principle, users should check the return code and always initialize their std::arrays, but in practice, it may be best to protect against this behaviour by creating a default return value (e.g. o2::track::DefaultDCA) and, in case the propagateToDCA call fails and the user provided some DCA, set the DCA to this default value. Further, in conformity with the DCA behaviour at analysis, this default value when propagation fails should be large (and not zero): in the propagation task at analysis, we use 999.f, so I'd propose to use that value directly as return value in case propagation fails.

Notably, the largest impact of this change is for low-p photon conversions (in which deep secondary e+ or e- often fail propagation). The svertexer accepts V0s made using such tracks, but analysis might not, since DCAs could be either uninitialized or set to zero (leading to rejection). Currently, the strangeness builder is safe against this behaviour, but multiple other tasks are not.

Tagging people I discussed this with recently: @njacazio @alcaliva @romainschotter

[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

[shahor02]

@ddobrigk thanks, then, for completeness, one should also do the same here:

AliceO2/DataFormats/Reconstruction/src/TrackParametrization.cxx

Line 381 in d56b3e9

return false;

,

AliceO2/DataFormats/Reconstruction/src/TrackParametrization.cxx

Line 402 in d56b3e9

return false;

and here:

AliceO2/DataFormats/Reconstruction/src/TrackParametrizationWithError.cxx

Line 230 in d56b3e9

return false;

,

AliceO2/DataFormats/Reconstruction/src/TrackParametrizationWithError.cxx

Line 248 in d56b3e9

return false;

Will you add it to this PR or you want me to do this?

[ddobrigk]

Hi @shahor02 indeed you're right, thanks, I can add that shortly!

[shahor02]

Thanks!

[ddobrigk]

@shahor02 Thanks a lot to you for taking a look! I have prepared also a message to the analysers to tell them about this, as there are really many tasks that may be affected due to not checking the return code. I'll send the message once this is merged.