Clean up TrackType enum

During the development of v3 tracks, a FittedForward track type was added to the track type enum, as a seemingly temporary solution(?).

By now this is quite confusing, and we should clean up the code such that the pattern recognition algorithm is again explained by the TrackHistory, and the fit status by the FitStatus enums. Note that no algorithms aside from those related to v3 tracks make use of this.

added RTA WP2 cleanup labels

assigned to @mveghel

changed the description

@gunther @ahennequ might know more why this is?

The track type FittedForward was the HLT1 CPU fast-Kalman-filtered Long track version. I touched the code recently and was also a bit annoyed by it as it only occurs in the outdated baseline scenarios. I completely agree that it should be dropped.

We should probably retire the number just to be sure (just in case it has been written/persisted). Maybe remove it and put a comment above that it is retired? What do you think?

In that case, I was also responsible and am happy to take the blame ;-) (but we should've used the other flags here)

Let's completely remove it...

I volunteer to do it

assigned to @gunther

unassigned @mveghel

mentioned in merge request !4419 (merged)

Hi all, i got to this issue after discussing a bit the current logics on the TrackBestTrackCreator with @sponce . I had a fast look in the code, and , altough i agree on dropping the HLT1 Long-Track making in CPU from the best track creator sequence, i was wondering if one should have a better look in the dependency the clone killer has with the order of the tracks? If so i can have a look on the logics and think wether we might have some issues. I suspect that regardless of the container of tracks passed to the BestTrackCreator we should define a pre-defined order of the track types. Would you agree on this?

I suspect this might have been a bug because of this line https://gitlab.cern.ch/lhcb/Rec/-/blob/2c61f61de6fbcc065a0ecc73da65e341e89b7eb7/Tr/TrackKernel/include/TrackKernel/TrackCloneData.h#L348 which does not implement a weight for the FittedForward type and silently returns a non-sense value when asking for it anyway, making the order random. This will be fixed by Rec@41465652 (Rec!3722 (merged)).

But on the same matter, this line https://gitlab.cern.ch/lhcb/Rec/-/blob/2c61f61de6fbcc065a0ecc73da65e341e89b7eb7/Tr/TrackUtils/src/TrackBestTrackCreator.cpp#L288 actually prefers the first track over the second one encountered which is debatable I guess. However, the order here is deterministic and cannot cause tests to fail.

closed with merge request !4419 (merged)

mentioned in commit b0579beb