ITS: GPU fix deltaROF tracking

[f3sch]

Fixes deltaROF on gpu and partially reverts some 'fix' for the combination deltaROF=1 + perPrimaryVertexProcessing. deltaROF still works as expected and the output has not changed.

[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

[mconcas]

Hi @f3sch , could you split this in two commits/PRs separating CPU changes from GPU ones, whenever it is doable?
Motivation is the usual facilitation for potential cherrypicking by disentangling the contributions.

[f3sch]

Certainly, the modifications to the Tracklet and TrackerSpec could be separate even though they are only cosmetic but the changes to the cpu/gpu codes should IMO go hand in hand as they bring them to the same state.

[mconcas]

Certainly, the modifications to the Tracklet and TrackerSpec could be separate even though they are only cosmetic but the changes to the cpu/gpu codes should IMO go hand in hand as they bring them to the same state.

What I mean is that flattening changes to different contexts/areas of the code in the same commit creates "dependencies" in case of the cherrypicking of that commit, that can then create conflicts if the states of the different contexts are not directly mergeable.
This increases the friction in the cherry-picking process and makes the process to take more time at least.
So, it is not really the cosmetics vs the improvements/fixes, but more the production (CPU) vs development/frontier(GPU, currently) one, in this specific case.

A good enough compromise is to push changes in different commits but same PR and then not to squash it. This does not provide full protection against build failures as the tested code is only the final state of the PR, but at least it leaves enough granularity for attempting the pick of the single commit, if needed.

This is of course under the assumption that we still live on cherry-pickings for some of the reconstruction tags. If it is never the case then disregard my comments and please let me know, so I'll stop being pedantic on this. :D

[f3sch]

Ok, I agree with making separate commits and not squashing them.
In general, I think one should be rigorous about potential cherry-picks.