Implementation of DQ monitoring of passed L1 and HLT chains and HLT RoIs overview histograms in Run 3

The changes in this MR will mean the following things:

• A histogram monitoring the counts of all passed HLT chains is added. The histogram is created in the py file, where it gets a number of bins equal to the total number of chains found in the AOD. It is filled in the cxx file. This histogram is very useful for reprocessings.
• A similar histogram monitoring all L1 items is also added, with the same basic access and functionalities.
• An overview histogram of phi vs eta for the RoIs of the passed HLT chains is also added. This is a sanity check to make sure not half of the muon trigger is gone for example.

Possible open items (could be addressed in a later MR):

• The chains and L1 items histograms typically end with some empty bins, because not all chains or L1 items are passed when I run over 20 events from a build file. This will be less of a problem for a full run.
• RoIs from HLT chains named HLT_noalg_* or HLT_beamspot_* seem to have eta = phi = 0 always. Is this expected?

Still missing:

• Chain and RoI monitoring for the signatures. In Run 2, this was done by a regex matching of chain names (see https://gitlab.cern.ch/atlas/athena/-/blob/master/Trigger/TrigMonitoring/TrigHLTMonitoring/python/TrigHLTMonitoringConfig.py#L10 ). Now we are discussing how to do that with offline monitoring groups. A simple name match might be a good cross check though.

Thanks!

Elin

============= Old description: ===============
I am trying to migrate the L1 overall monitoring histogram to the Run 3 framework. The Run 2 equivalent is here: https://atlasdqm.cern.ch/webdisplay/tier0/1/physics_Main/run_360026/run/HLT/TRHLT/L1Events

This is obtained by retrieving all L1 triggers from the TriggerDecisionTool ( https://gitlab.cern.ch/atlas/athena/-/blob/master/Trigger/TrigMonitoring/TrigHLTMonitoring/src/HLTMonTool.cxx )

In Run 3 /MT I have learned that getTrigDecisionTool doesn't return an instance of TrigDecisionTool, but rather configures it and returns a ComponentAccumulator.

@tamartin suggested that it would be better if these data were accessed at configure-time through the metadata peeker and stored in the config flags. "I.e. we could set the ConfigFlags.Trigger.HLTChains flag to a lambda function which would auto-populate it with an array of strings from the in-file metadata."

The committed code is my current attempt after help from Tim and @rbielski. It compiles but fails with
AttributeError: 'TrigDecisionTool' object has no attribute 'getChainGroup' because there is no getChainGroup in the current TDT.

I also tag @fwinkl , @tbold , @ponyisi , @smh for discussion about how to proceed.

This is related to Jiras ATR-21172 and ATR-19976