CI: bump cibuildwheel, drop 3.7 testing

[shanedsnyder]

This started as a PR for simply bumping cibuildwheel to 2.17 to allow Python 3.12 wheel builds.

Along the way, I found that:

• Python 3.7 is EOL and no longer available in macos-latest, so I've dropped it from the main-ci test matrix.
• libtool needs to be explicitly installed via brew on new macos-latest
• For whatever reason, the darshan-util install process in cibuildwheel was failing to the default output directory (I think /usr?), so I reworked the build to install to a non-system location and updated LIBRARY_PATH env variables to point to it.

[tylerjereddy]

Just a few comments from looking through the diff and CI log:

• are we intentionally switching from x86_64 to ARM support for all our shipped MacOS wheels now (you can see they're all arm builds in the log output)? I think this may be an unintentional results of us using macos-latest image rather than a pinned image, and having that point to an M1 arch machine now per: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners ; cool result that we could probably ship all these ARM wheels if we wanted; not sure that we'd want to get rid of x86_64 mac just yet, maybe, but wanted to make sure that was clear
• perhaps a bit unusual that we'd ship Linux Python 3.7 wheels but not MacOS; I guess if there are HPC centers with ancient Python I suppose I could see the justification for that asymmetry though (probably bound to break pretty soon though, given removal from main CI for 3.7)

[shanedsnyder]

Thanks for having a look @tylerjereddy.

are we intentionally switching from x86_64 to ARM support for all our shipped MacOS wheels now (you can see they're all arm builds in the log output)? I think this may be an unintentional results of us using macos-latest image rather than a pinned image, and having that point to an M1 arch machine now per: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners ; cool result that we could probably ship all these ARM wheels if we wanted; not sure that we'd want to get rid of x86_64 mac just yet, maybe, but wanted to make sure that was clear

Good catch, I probably should have noticed this one but guess I was scanning too quickly after fighting to get any wheels produced at all. Unless you have another suggestion, I can try to look and see if I can update our wheel building workflow to generate both arm and x86_64 wheels for macos -- I suppose that could maybe be accomplished by adding a pinned macos to the OS matrix there (in addition to macos-latest)? I can take a look and see if I can set it up. I guess the main_ci workflow should be updated, too, so that our general Python testing is running on each arch, but I won't look at that here.

perhaps a bit unusual that we'd ship Linux Python 3.7 wheels but not MacOS; I guess if there are HPC centers with ancient Python I suppose I could see the justification for that asymmetry though (probably bound to break pretty soon though, given removal from main CI for 3.7)

I had noticed this and wasn't quite sure initially how to handle. Maybe just for the sake of consistency across architectures, I'll just update cibuildwheel workflow to only do 3.8+. I doubt there's really much appetite for EOL Python versions, even in HPC centers that seem to upgrade this sort of stuff really slowly. FWIW, I see versions 3.9 and 3.11 available on a couple of our production Cray-HPE systems at the ALCF.

[shanedsnyder]

Okay, I think that's all sorted now. All checks are passing, and now we get 3.8-3.12 wheels for manylinux-x86_64, macosx-x86_64, and macosx-arm64. Not sure if overkill, but this workflow isn't something we really need to run regularly (just a few times a year on releases, and other ad-hoc debugging workflows).

[tylerjereddy]

LGTM now, merged, thanks