JCF: for added peace of mind while refactoring HDF5DataStore, add som…

[jcfreeman2]

…e more HDF5 writing unit tests

These are all exception-focused, including:

• What happens if you try to write the same timeslice twice
• What happens if the output path you specify doesn't exist
• What happens if you specify that the max file size is unrealistically large

Description

Basically, description is provided in the commit comment.

To review, just check that the unit tests accurately capture the current behavior of HDF5DataStore.

Type of change

• Documentation (non-breaking change that adds or improves the documentation)
• [ X] 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)

Testing checklist

• [ X] 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)

Further checks

• [X ] Code is commented where needed, particularly in hard-to-understand areas
• [X ] 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]

I'll point out that the reason the single repo CI workflow failed is because the linter will lint #included headers which are locally available; the fact that this PR adds an #include of the HDF5DataStore header to the HDF5Write_test adds the new linting warnings - and hence aren't the fault of the code in this PR per se.

[eflumerf]

Looks good. Unit test builds and passes