AOD producer: improve MC collision labels for embedded events

[sawenzel]

In embedding scenarios where a single background event is reused across multiple collisions, e.g.:

Collision 0: Background 0 + Signal 0
Collision 1: Background 0 + Signal 1
Collision 2: Background 0 + Signal 2
Collision 3: Background 0 + Signal 3
Collision 4: Background 0 + Signal 4

the primary vertexer may return MC labels all pointing to "Background 0". This caused an ambiguous lookup in the AOD producer, resulting in all reconstructed collisions being incorrectly associated to the same MCCollision entry.

This is addressed by collecting all MCCollision candidates matching a given (sourceID, eventID) label and disambiguating via bunch-crossing time, picking the MCCollision whose BC is closest to the reconstructed vertex time.

Note: a more robust long-term solution would be to extend the primary vertexer to return the full set of contributing MC labels per found vertex, enabling simpler and more reliable disambiguation strategies.

This relates to https://its.cern.ch/jira/browse/O2-6840.

[shahor02]

@sawenzel currently the PVertex MCEventLabel follows the same schema as for other reconstructed objects: it corresponds to the label of the majority of contributors (additionally storing also the fraction of this majority).
In principle, independently of this MCEventLabel, which I would not touch, I could store a vector MC events contributing to the given PV. But as far as I understand, propagating this vector to the AOD would require adding a new (small) labels tree.
Still, I am not sure how this would resolve the ambiguity: a reconstructed vertex often contains a few wrongly attached tracks from different event. What will you do for the vertex with the MC event labels {BackgroundA, BackgroundB, SignalC, SignalD}?

[sawenzel]

@shahor02 : Thanks for the info. I think returning more information will just help for disambiguation.
Finally, I think that we could also improve the label system overall. Instead of referring to MCEvent labels (without time assigned), we could try to forward MCCollision labels (identifying collisions in the collision context .. that include time information). This will carry better MCTruth and would avoid the current problem.