[PWGHF] Implement gen and reco MC matching for correlated bkg decays

[Marcellocosti]

In this PR, the matching for the study of the correlated background decays implemented in the linked configuration script is implemented for 2-prong and 3-prong candidates both at reco and at gen level.

By now I keep the PR in draft mode as there are several debug prints for the checks on the matching I am performing and because I will need to digest the rearrangement of the MC flags proposed in the PR #11382 when merged. Nevertheless, a feedback on the general structure is more than welcome. Tagging @stefanopolitano for info.

The modifications to the D0 and D+ trees are for testing purposes.

[github-actions]

O2 linter results: ❌ 8 errors, ⚠️ 0 warnings, 🔕 20 disabled

[mfaggin]

ciao @Marcellocosti thanks a lot for this important development. I had a look at it and I tried to understand the logic you want to implement. I have left some comments here and there to understand if I get exactly what you mean, please let me know what you think.

[Marcellocosti]

Dear @vkucera, I implemented your comments and also changed the handling of the Dstar matching for the reconstructed to be similar to the generated candidates. Please let me know if I missed something!

[vkucera]

Thanks a lot @Marcellocosti for the great work!

[lubynets]

Dear @Marcellocosti (all code owners cc), shouldn't it be kKPlus instead of kPiPlus here?

[vkucera]

Why?

[lubynets]

Since the decay is $\pi KK$, so swapped means $KK\pi$, i.e. the 0-th daughter pdg code should be kaon's. Compare to $pK\pi$ decay here - there is comparison to pion's pdg code since it is the last in the original, non-swapped order.

[vkucera]

But the expected order is defined as KKPi here in:

auto arrPdgDaughtersDToPiKK{std::array{+kKPlus, -kKPlus, +kPiPlus}};

[lubynets]

But the expected order is defined as KKPi here in:

auto arrPdgDaughtersDToPiKK{std::array{+kKPlus, -kKPlus, +kPiPlus}};

Indeed, if the $K^+K^-\pi^+$ order is assumed as default (= expected), then the definition of swapped goes other way around, and the code is correct in terms of logic.
But is there any reason to define the expected order of prongs different from how they appear in the dedicated enum and its comment (link)? The way how it is implemented now requires checking the source code deeply (line which you quote), while the enum hints another expected order (very intuitive but wrong).

[lubynets]

@vkucera, no, I think that the arrPdgDaughtersDToPiKK in this context is not responsible for definition of expected order (?) What is really responsible is the r.h.s. of the
swapping = int8_t(std::abs(arrayDaughters[0].mcParticle().pdgCode()) == kPiPlus);
comparison, since precisely this line defines whether swapping flag will be 0 or 1.