ATR-24326 Change the horizontal merging order to match chain order
Changes how menu sequences are arranged within a step for combined chains - instead of arranged by which "happens" first, they're arranged by the order in the chain.
For example, for HLT_e5_probe_mu10, on the first step (muons running before e probe) -
--- ChainStep merged_1mufast_EmptyMuonAlign1_1Electron --- multiplicity = 1 1 ChainDict = leg000_HLT_e17_lhloose_mu14_L1EM15VH_MU8F leg001_HLT_e17_lhloose_mu14_L1EM15VH_MU8F + MenuSequences = STrigL2MufastHypoAlg EmptyMuonSeq1_Electron
--- ChainStep merged_EmptyMuonAlign1_1Electron_1mufast --- multiplicity = 1 1 ChainDict = leg000_HLT_e17_lhloose_mu14_L1EM15VH_MU8F leg001_HLT_e17_lhloose_mu14_L1EM15VH_MU8F + MenuSequences = EmptyMuonSeq1_Electron STrigL2MufastHypoAlg
Along the way, I found a few bugs that needed fixing:
regex matching to remove duplicate StepN_ before step renumbering was only matching single digits. Now fixed to handle single or double. Deliberately did not account for > 99 steps because if we ever get there we should take a serious look at what we're doing...
in the situation where we have combined chains where one signature had at least two legs, and there was an alignment group between the other alignment groups that needed empty step padding, the alignment would put steps in the wrong spot and the code would fail.
A concrete example is:
- alignment is egamma, mu, tau, jet
- chain is e12_lhloose_e10_lhloose_j20
the alignment would put the empty mu and tau steps in the wrong place. We had never encountered a situation like this before (no such triggers in the menu) so the bug remained hidden.
this is now fixed. It should resolve the issues seen in ATR-23507.