Update Ubuntu CI runner from old AWS c6i ParallelCluster to c6a single-node instance

[ashley314]

Summary

• Update the Ubuntu CI workflow to (a) run on a newly provisioned c6a single node instead of an old c6i ParallelCluster that is now in a state where it can't be updated anymore, and (b) build Intel and GNU environments in two steps: first create a buildcache, then an actual environment from it. The buildcache can be used to create spack-stack environments for other CI testing by JCSDA (simobs, skylab, ufs-bundle).
• Use tag v1.3.0 of the CMakeModules submodule - no code changes here, we tagged the commit that spack-stack was pointing to for several releases as v1.3.0.
• Update submodule pointer for spack for a few accumulated changes, including Add -fPIC to hdf-eos2 builds spack#426 which is required for this PR.

Testing

• CI - see below
• Container CI - see https://github.com/JCSDA/spack-stack/actions/runs/8825426794

Systems affected

CI testing

Issue(s) addressed

Working towards https://github.com/JCSDA-internal/CI/issues/118

Dependencies

• Waiting on Add -fPIC to hdf-eos2 builds spack#426

Checklist

• This PR addresses one issue/problem/enhancement, or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.

[climbfuji]

This is finally ready for review. I also ran the container CI test (needs to run from a branch in the spack-stack repo) and it was successful: https://github.com/JCSDA/spack-stack/actions/runs/8825426794

[climbfuji]

This is almost a copy of the .github/workflows/ubuntu-ci-x86_64-intel.yaml workflow. There are subtle differences and I thought it might be better to keep them apart, even though this means some amount of code duplication. We could move some of the steps into a common/shared workflow file and draw from there in the future ...

[climbfuji]

I adopted this logic from the previously removed workflow on the AWS ParallelCluster (R&D cluster)

[climbfuji]

I contributed many of the changes in this PR, therefore I should not be approving it. But I am obviously happy with it :-)

[climbfuji]

@ashley314 Can you please do a self-review of this PR, especially all the changes I added on top of yours (apologies for the many updates)? Thanks!

[ashley314]

Will do! @climbfuji thanks for all of the updates

[ashley314]

I'm not able to approve this PR, but I reviewed and everything looks good. Thank you for getting these working!

[climbfuji]

@AlexanderRichert-NOAA Do you have time for a review of this?

[srherbener]

Why do the file names not contain the "c6a" marking, but the internal names in the configuration do contain "c6a"? Just want to check if this was what was intended. Thanks!

[climbfuji]

Why do the file names not contain the "c6a" marking, but the internal names in the configuration do contain "c6a"? Just want to check if this was what was intended. Thanks!

Only the name of the runner differs, which is totally independent of the yaml.

[srherbener]

Why do the file names not contain the "c6a" marking, but the internal names in the configuration do contain "c6a"? Just want to check if this was what was intended. Thanks!

Only the name of the runner differs, which is totally independent of the yaml.

Sounds good. I just wanted to double check.