treewide: use PODIO ObjectID instead SimID/RecID indices

[veprbl]

Briefly, what does this PR introduce?

This is a subset of #970, that removes use of SimID and RecID fields (while switching to comparisons of full object id's instead of just the indices).
In principle, we could even drop .getObjectID() in comparisons and just use Object::operator== https://github.com/AIDASoft/podio/blob/400f4f06bef3e7666c71e31be579ec715c412b8a/python/templates/macros/implementations.jinja2#L160, which relies on pointer comparison instead.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No

Does this PR change default behavior?

No

[github-actions]

Capybara summary for PR 1346

• rec_dis_10x100_minQ2=1000_craterlake
• rec_dis_10x100_minQ2=1_craterlake
• rec_dis_18x275_minQ2=1000_craterlake
• rec_dis_18x275_minQ2=1_craterlake
• rec_dis_5x41_minQ2=1_craterlake
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-03-24T05:07+00:00 0bde6f7}}

[simonge]

If this is just a purge of using SimID and RecID then looks good. Otherwise it might be a good idea to remove all calls to .index other than in log outputs so the check that it really is the same object from the correct collection is in place and not something from another collection with the same index.

What is the argument against comparing the objects as opposed to using getObjectID?

[veprbl]

If this is just a purge of using SimID and RecID then looks good. Otherwise it might be a good idea to remove all calls to .index other than in log outputs so the check that it really is the same object from the correct collection is in place and not something from another collection with the same index.

Note, this is already removing calls to .index in comparisons, so both index and collection ID are being compared.

What is the argument against comparing the objects as opposed to using getObjectID?

Not really an argument. I'm just having hard time convincing myself that pointer comparison will always do what we want. You think it's fine?

[simonge]

Note, this is already removing calls to .index in comparisons, so both index and collection ID are being compared.

The use as mcID in MatchClusters could probably just drop the .index and still work equivalently. There is other cleaning up that could be done in the algorithm anyway so could be deferred.

What is the argument against comparing the objects as opposed to using getObjectID?

Not really an argument. I'm just having hard time convincing myself that pointer comparison will always do what we want. You think it's fine?

I just thought it would look cleaner, keeping getObjectID is probably the more sensible approach.

[simonge]

MatchClusters wouldn't be a simple change so happy within the PR scope