Fix use of NSST in GCAFS

[CoryMartin-NOAA]

Description

This PR fixes 2 bugs:

1. GCAFS was naively using the NSST increment from GDAS, because the filename suggested it was an analysis and not an increment. A new utility is being added to GFS-Utils to calculate this instead of just using it directly
2. Rename the files so that this mix up won't happen in the future

Resolves #4291

Note this will require a file addition to the tars stored on MSU HPC before those tests will pass successfully

Type of change

• Bug fix (fixes something broken)
• New feature (adds functionality)
• Maintenance (code refactor, clean-up, new CI test, etc.)

Change characteristics

• Is this change expected to change outputs (e.g. value changes to existing outputs, new files stored in COM, files removed from COM, filename changes, additions/subtractions to archives)? YES
  • GFS
  • GCAFS
• Is this a breaking change (a change in existing functionality)? NO
• Does this change require a documentation update? NO
• Does this change require an update to any of the following submodules? YES
  • GFS-utils Add utility to compute NSST increment for GCAFS gfs-utils#165

How has this been tested?

Built and tested on Ursa, would like a longer test to see if it fixes the observed problem

Checklist

• Any dependent changes have been merged and published
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have documented my code, including function, input, and output descriptions
• My changes generate no new warnings
• New and existing tests pass with my changes
• This change is covered by an existing CI test or a new one has been added
• Any new scripts have been added to the .github/CODEOWNERS file with owners
• I have made corresponding changes to the system documentation if necessary

[XuLi-NOAA]

Comments:

1. Originally, the file dtfanl was named to represent the dela (increment) of Tf analysis). I agree it needs a better name to be consistent with others.
2. The Tf analysis is generated through global_cycle, in which the Gaussian grid Tf analysis incement is intepolated to FV3 native grid and then added to the background (fitst guess) in global_cycle, which is a utility of UFS_UTILS.
3. The SST and surface salinity alimatology are used in global_cycle to address some grids where no nearby water grids available from dtfanl and the newly generated ice.

[CoryMartin-NOAA]

Thanks @XuLi-NOAA is the approach here: NOAA-EMC/gfs-utils#165 reasonable?

[bbakernoaa]

After resolving the conflicts, I approve. This seems to produce reasonable results even after 30+days of cycling

[CoryMartin-NOAA]

I think this PR is ready for final review and testing. Any changes needed for the pres_b archiving should go in a different PR.

[CoryMartin-NOAA]

I will run the GCAFS C96_cycled test on Ursa to test and fetch the new files needed, then will copy to MSU and test there. If this happens before the PR is merged, I will re-activate the MSU CI, otherwise I will reactivate that in a future PR (it will require an update of the staged input tar ball)

[TravisElless-NOAA]

Only thing I saw off the bat

[CoryMartin-NOAA]

I've reverted the changes turning off the MSU CI tests. The Tref code runs on Orion and once the updated files have been staged, should pass the CI test.

[TravisElless-NOAA]

Things are fine to me here. Approving pending testing and staging of the MSU files

[DavidHuber-NOAA]

@CoryMartin-NOAA let me know if/when you need something staged in the glopara space on MSU.

[CoryMartin-NOAA]

@DavidHuber-NOAA yes please, see #3806 (comment)

[TravisElless-NOAA]

Since files have now been staged, will (attempt to) launch Hercules CI

[CoryMartin-NOAA]

Hercules CI passed. Anything else I need to do?