Parallel HDF5: Try fixing strict collective requirements of HDF5 >= 2.0

[franzpoeschel]

It seems that HDF5 has become quite a bit pickier about metadata definitions in parallel setups with versions 2.0 and 2.1, leading to hangups.
Earlier, it was enough to define them consistently across ranks, now we apparently have to keep the exact same order of operations.

This is bad for the Span API which runs internal flushes for structure setup.

• No longer flush inside the Span API, instead flush already at resetDataset()
• Try if we can only enqueue operations and run them later, should be fine for the ordering
• Ensure that only a select type of operation runs in structural setup flushes
• Remove flushParticlesPath and flushMeshesPath functions, these unnecessarily leaked attribute flushes into the structure setup
• Fix tests...
• Manually go through tests and check if any of them silently swallows some errors, the chance is high
• Guard setDirty calls
• There are some commits deactivating a handful of tests, deal with them
• Decide how to go forward with the changes inside resetDataset(). Best idea: add the new logic to a new API call commitStructuralSetup() or so.
  • Ref. also HDF5: Close operations also upon failure #1866 for defer_type
  • Ref. also Write scientific defaults upon close (Iteration::close or Series::close) #1834 for commitStructuralSetup()

Diff at https://github.com/franzpoeschel/openPMD-api/compare/defaults-upon-close...fix-parallel-hdf5?expand=1

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.