DQM: header and namespace cleanup

[schneiml]

PR description:

This PR separates a few changes out of the big DQMStore restructuring project [1] that can be merged safely. No behaviour changes. These changes include things that need to be fixed/explicitly declared in subsystem code, therefore this PR touches many packages and will conflict almost certainly with others.

This is the reason to split out these changes and merge them now.

There are two big sets of changes:

• Simplify includes. The only files to be included from the DQMServices/Core package are DQMStore.h and the module base classes (DQMEDAnalyzer.h, DQMEDHarvester.h, oneDQMEDAnalyzer.h, DQMGlobalEDAnalyzer.h). All others should the replaced with DQMStore.h.

  • This implies that MonitorElement.h should never be included, the majority the majority of changes is removing these.
  • There are still a lot of redundant includes and a few non-standard ones, that I did not bother to hunt down.
  • DQMStore and MonitorElement should never be forward-declared, to prevent problems in the next steps.

• Namespace MonitorElement and DQMStore into dqm::reco::, dqm::harvesting:: and dqm::legacy:: (and dqm::impl::, which is the actual implementation).

  • There is (intentionally) now more DQMStore and MonitorElement in the default namespace. Most code will continue to work unchanged since DQMEDAnalyzer and DQMEDHarvester import them into class scope.
  • For now all of these are the same class, but in the future they will start to expose different APIs.
  • All legacy modules, that is those using DQM but not deriving from DQMEDAnalyzer or DQMEDHarvester, need to import the correct definition themselves. typedefs to to that are the second big batch of changes.
  • Many of the classes that now import dqm::legacy:: are actually helper classes and not legacy modules by themselves. These could be changed to dqm::reco:: or dqm::harvesting:: based on the APIs that they use, but that will be easier once the reduced APIs are actually in place.
  • The only visible change in non-legacy code is that functions returning MonitorElement defined outside the class declaration now need to qualify the MonitorElement in their return type. This is due to how C++ scoping works and hard to avoid.

In addition,

• A lot of DQMServices/Examples is deleted, since it demonstrates the usage of legacy APIs, some of which are only used in the example code...
• MonitorElement::Kind got turned into an enum class to keep things a bit more clean in the future.

PR validation:

Code compiles.

None of the changes should affect the output, but bugs and mistakes are possible, so we need to watch the comparisons.

PR comparison shows no significant changes.

[1] master...schneiml:dqm-new-dqmstore-on-CMSSW_11_0_0_pre1-from-andrius

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27476/10805

• This PR adds an extra 3920KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File DQM/GEM/plugins/GEMDQMStatusDigi.cc modified in PR(s): GEM vfat dataformat update v301 #27419
  • File DQMServices/FwkIO/plugins/DQMRootSource.cc modified in PR(s): Added additional exception info to DQMRootSource #27473
  • File Validation/RecoTrack/interface/MTVHistoProducerAlgoForTracker.h modified in PR(s): MTV : add chi2_vs_pt, assoc_chi2_vs_pt and assoc_chi2prob_vs_pt #27345
  • File Validation/RecoTrack/src/MTVHistoProducerAlgoForTracker.cc modified in PR(s): MTV : add chi2_vs_pt, assoc_chi2_vs_pt and assoc_chi2prob_vs_pt #27345

[fabiocos]

@schneiml @ssekmen @sbein as ME are commented, is this (and the previous update to BuildFile) really needed? Otherwise it would be good to clean it (possibly in a separate PR)

[fabiocos]

@qliphy @efeyazgan @alberto-sanchez please check also the update in your domain, it looks straightforward

[pohsun]

+1

[alberto-sanchez]

+1

indeed the changes are associated to RivetInterface and are straightforward

[ggovi]

+1

[fabiocos]

@schneiml I assume this is ok for you, please sign it, I would like to merge it tomorrow

@civanch @sbein @ssekmen @rekovic @peruzzim the updates in your are look ok to me, please check them anyway

[ssekmen]

+1

[fabiocos]

@schneiml @andrius-k @jfernan2 ping

[jfernan2]

+1
@fabiocos Marcel is on holiday this week, I believe he was OK with merging it, we clearly forgot to discuss this on last Friday meeting, I cannot comment on the PR notes made though

[civanch]

+1

[fabiocos]

+1

[fabiocos]

merge