WIP: Dropping SignalState features from xAOD::CaloCluster
The ability of xAOD::CaloCluster to present itself in various signal states is a threading problem. To first order, the issue has been solved by @christos in https://gitlab.cern.ch/atlas/athenaprivate1/merge_requests/14465 by disallowing state-changes for const clusters. This defeats the initial purpose of signal-states and the fact that it works suggests that the feature is not used in practice.
Grep'ing through the repository, I find indeed (almost) no uses of signal-state functionality. I did find includes-without-usage, debug-level printouts and HLT-monitoring of the signal-state of clusters. All that is practically meaningless and I deleted these lines with this MR.
On the cluster object itself, I remove the transient variable storing the signal state and its setters and getters. The methods implementing the IParticle interface will always return the calibrated state. The un-calibrated kinematics is still accessible by calling eg cluster->eta(xAOD::CaloCluster::UNCALIBRATED). To allow passing un-calibrated clusters as IParticle to tools, I wrote a thread-safe wrapper object that implements the IParticle interface and forwards calls to cluster with a given signal state (xAODCaloCluster/CaloClusterSignalstate). But since I havn't found any use-case, I might remove that before un-wip'ing this MR.
Remaining problem: METReconstruction/METJetAssocTool This tools compares the signal state of the jet and the clusters the jet was made of and behaves differently depending on the result. I don't quite understand what is going on here and I suspect it makes no sense: In the old scheme, the signal state might have been changes between the jet-finding and the MET-Association. With Christos' MR, it can't change and in real life it will never be anything but CALIBRATED. I hope @khoo can help here (git blame says you wrote that).
Possible problem: I deleted TrigHLTJetRec/src/ClusterToPseudoJetConverter. In the current HEAD of master, all uses of this helper are commented out (by @peter, afaik). A different implementation would be necessary achieve the same functionality w/o the signal-states.