WIP DAQSys - Add option to switch to Run1 RICH decoder and use in QM tests
Adds a fix (workaround) for the issues discussed in !2226 (merged)
Core issue is the DAQSys tests in question are running on old Run1 (2012) data but using the new RICH (functional) decoder being developed for Run III. This decoder was updated in !2226 (merged) to use the new functional approach to loading detector elements, and this has caused a change in when certain RichDet objects are first instantiated. Previously this was done during the application initialisation phase, but now it is done after the first event is read in. This means a different IOV is being used, and this has lead to some DB inconsistency/bug/??? being exposed.
The new approach to conditions is much stricter (and better at) enforcing detector elements are initialised with the correct IOV context, so the new approach is 'correct' even if it is exposing this issue. For that reason I am not proposing we just forget about the issue seen in the above MR, we should investigate to see if there is a deeper issue we need to learn from, or if its just an issue of combining old data with the current state of master. This MR though will allow that to be done independently of reviewing and merging !2226 (merged), which I would very much like to do as I have a bigger update being developed (see !2230 (merged) and its dependents in Lbcom and Rec) that I would prefer not to hold up.
What this MR does is simply to switch back to the older decoder set up (as actually used during Run1) for these tests. Longer term these tests should probably also be reviewed a bit, (do we want to update them to newer RunII data ?) but again this MR is just to maintain the status quo, and that can then follow later on.