WIP: Gaudi Upgrade, master branch (2020.11.05.)

This is a first attempt at building the Athena project against the current master of Gaudi. Making use of the re-written CMake configuration of that project.

This is WIP, which will be run through the CI every once in a while. But the final MR should be created separately. (This repository's history doesn't need to include a reference to the GaudiBuildUpdate-master-20200708 branch of my fork of atlas/atlasexternals). Naturally, this MR will go hand-in-hand with atlasexternals!699 (merged).

At this point, with the changes to the build scripts, and the few minor fixes in the source code, I can compile "pretty much all of" Athena. The problem, as you'll see in the CI's build, is that the new Gaudi CMake configuration disabled some hacks that were introduced for ATLAS's sake a long-long time ago. Very notably GaudiSvc/ExtraModules.py is not included by GaudiSvc.GaudiSvcConf automatically at the moment (or anymore...). Leading to the following kind of issue as soon as one tries to use athena.py:

Py:TriggerMenu.api.TriggerAPI.py    INFO Found pickle file:/cvmfs/atlas.cern.ch/repo/sw/database/GroupData/TriggerMenu/TriggerInfo_20181112.pickle
Traceback (most recent call last):
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/bin/generateUnprescaledLists.py", line 36, in <module>
    sys.exit( main(sys.argv[1]) )
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/bin/generateUnprescaledLists.py", line 15, in main
    outfile.write( to_nice_list( TriggerAPI.getUnprescaled(TriggerPeriod.future1p8e34, triggerType), triggerType.name) )
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerMenu/api/TriggerAPI.py", line 109, in getUnprescaled
    cls._loadTriggerPeriod(period,reparse)
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerMenu/api/TriggerAPI.py", line 169, in _loadTriggerPeriod
    cls.dbQueries[(period,cls.customGRL)] = TriggerInfo(period,cls.customGRL,cls.release)
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerMenu/api/TriggerInfo.py", line 25, in __init__
    HLTlist, totalLB = getHLTlist(period, customGRL, release)
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerMenu/api/TriggerDataAccess.py", line 354, in getHLTlist
    hltmap, totalLB = getHLTmap_fromTM(period, release)
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerMenu/api/TriggerDataAccess.py", line 311, in getHLTmap_fromTM
    from TriggerJobOpts.TriggerFlags import TriggerFlags
  File "/cvmfs/sft.cern.ch/lcg/releases/LCG_98python3_ATLAS_2/ROOT/v6.22.00/x86_64-centos7-gcc8-opt/lib/ROOT/_facade.py", line 121, in _importhook
    return _orig_ihook(name, *args, **kwds)
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerJobOpts/TriggerFlags.py", line 738, in <module>
    class menuVersion(JobProperty):
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/TriggerJobOpts/TriggerFlags.py", line 743, in menuVersion
    from AthenaCommon.AppMgr import release_metadata
  File "/cvmfs/sft.cern.ch/lcg/releases/LCG_98python3_ATLAS_2/ROOT/v6.22.00/x86_64-centos7-gcc8-opt/lib/ROOT/_facade.py", line 121, in _importhook
    return _orig_ihook(name, *args, **kwds)
  File "/data/projects/gaudi/build/x86_64-centos7-gcc8-opt/python/AthenaCommon/AppMgr.py", line 100, in <module>
    GaudiSvcConf.ToolSvc.__iadd__ = iadd
AttributeError: module 'GaudiSvc.GaudiSvcConf' has no attribute 'ToolSvc'

I wanted to discuss it on this MR, how we should deal with this. I see the following options:

• We add some switch(es) to the Gaudi configuration itself to make it behave like it used to. See:

https://gitlab.cern.ch/gaudi/Gaudi/-/blob/master/GaudiSvc/CMakeLists.txt#L35

• We add a "tricky" GaudiSvcConf.py file to our own repository, which would be installed in such a way that it would be picked up instead of Gaudi's module by default. In this module we could make sure that it would behave (for now) as our code would expect.
• We just update all Python code in this repository to pick up the Gaudi services from their correct locations.

I think the prudent way is probably "option 2" in this MR, and then an implementation of "option 3" in an MR later on. (Once we're already using the new Gaudi version.)

Pinging some people on this: @clemenci, @leggett, @fwinkl, @bwynne.