Update and fix HDF5 coding in various plugins

[markcmiller86]

Description

Many of our HDF5 plugins were still running H5_USE_16_API code. I asked Codex to help with...

• Update API usage to HDF5 2.0
• Fix any int/hid_t and int/herr_t confusions encountered (In older HDF5, hid_t was int but not any longer).
• Fix any incorrectly paired H5Xopen()/H5Xget_Y() with H5Xclose()/H5Yclose(). Missed pairings can cause leaks and prevent a later HDF5 plugin from opening a file left open from an earlier HDF5 plugin attempted during auto-detection.

Type of change

• Bug fix~~
• [ ] New feature
• [ ] Documentation update
• Other: Update to newer HDF5 library API

How Has This Been Tested?

I ran all database tests on CZ system. Results posted in two tarfiles here. All failures are understood and expected.

• html_part1.tar.reallyxz.gz
• html_part2.tar.reallyxz.gz

Reminders:

• Please follow the style guidelines of this project.
• Please perform a self-review of your code before submitting a PR and asking others to review it.
• Please assign reviewers (see VisIt's PR procedures for more information).

Checklist:

• [ ] I have commented my code where applicable.
• I have updated the release notes.~~
• [ ] I have made corresponding changes to the documentation.
• [ ] I have added debugging support to my changes.
• [ ] I have added tests that prove my fix is effective or that my feature works.
• I have confirmed new and existing unit tests pass locally with my changes.~~
• [ ] I have added new baselines for any new tests to the repo.
• I have NOT made any changes to protocol or public interfaces in an RC branch.~~

[cyrush]

For H5Gopen2 cases, with the latest HDF5 API - wont H5Gopen map to H5Gopen2?

So we need the signature changes but not 2 suffix call changes?

[cyrush]

Most of these changes are straight forward -- we should scrutinize the iteration callbacks b/c those are the most complex aspect.

[markcmiller86]

Most of these changes are straight forward -- we should scrutinize the iteration callbacks b/c those are the most complex aspect.

Oh, good idea. I was at least going to see if this update resolves the memory issues I am seeing when reading Pixie data (which triggers attempts to open and read from 8 different HDF5 plugins).

For now, my goal was to just get this work pushed somewhere useful. I don't think we need to worry about it prior to 3.5.0 release. But, thats your call too.

[markcmiller86]

For H5Gopen2 cases, with the latest HDF5 API - wont H5Gopen map to H5Gopen2?

So we need the signature changes but not 2 suffix call changes?

Hmmm...I didn't look at that but yes, by default, HDF5 library contains macros for all API changes so that H5Gopen is macro-mapped automagically by hdf5.h to the default API (which in this case I think is H5Gopen2.

Honestly, I kinda prefer that way than writing code that explicitly calls out a specific version of the API method (e.g. H5Gopen2() or H5Gopen3(), etc.

But, it looks like Codex was not consistent in how it chose to resolve that in this case.