JCF: DUNE-DAQ/daqdataformats#79: replace daqdataformats::TriggerRecor…

[jcfreeman2]

…dHeader::operator[] with daqdataformats::TriggerRecordHeader::at, which performs the identical function and hasn't been removed from the code

Description

In TRBModule a call to daqdataformats::ComponentRequest::operator[] is replaced with a call to daqdataformats::ComponentRequest::at as the former has been removed for reasons described in DUNE-DAQ/daqdataformats#81. Note at does exactly the same thing operator[] did.

To test the changes, make sure the code still builds, alongside daqdataformats and dfmessages checked out to the branches of the same name, johnfreeman/daqdataformats_issue79_code_refactoring. Also confirm for yourself by looking at daqdataformats::ComponentRequest::at that it does the same thing daqdataformats::ComponentRequest::operator[] did.

Type of change

• Documentation (non-breaking change that adds or improves the documentation)
• New feature or enhancement (non-breaking change which adds functionality)
• Optimization (non-breaking change that improves code/performance)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (whatever its nature)

I suppose this is an optimization in the sense that dfmodules won't build unless this is merged once DUNE-DAQ/daqdataformats#81 is merged into daqdataformats.

Testing checklist

• Unit tests pass (e.g. dbt-build --unittest)
• Minimal system quicktest passes (pytest -s minimal_system_quick_test.py)
• Full set of integration tests pass (dunedaq_integtest_bundle.sh)
• Python tests pass if applicable (e.g. python -m pytest)
• Pre-commit hooks run successfully if applicable (e.g. pre-commit run --all-files)

Comments here on the testing

Further checks

• Code is commented where needed, particularly in hard-to-understand areas
• Code style is correct (dbt-build --lint, and/or see https://dune-daq-sw.readthedocs.io/en/latest/packages/styleguide/)
• If applicable, new tests have been added or an issue has been opened to tackle that in the future.
  (Indicate issue here: # (issue))

[jcfreeman2]

Closing this as I'm reconsidering the removal of daqdataformats::ComponentRequest::operator[]

[jcfreeman2]

Reopening (although still in Draft form) in light of daqdataformats commit 45a02b2c8748 in DUNE-DAQ/daqdataformats#81

[jcfreeman2]

n.b. The reason the single-repo CI workflow is in error is due to a bug in the workflow itself, and not through the fault of the code in this PR (it's inappropriately complaining about linting problems with dfmessages, a problem which got fixed after this PR was opened in DUNE-DAQ/.github#18).

[eflumerf]

See comment in github.com/DUNE-DAQ/daqdataformats/pull/81