Add policies toward coupling and absorb policies into GDAS/atmosphere

[danholdaway]

In this PR we add more testing and policies ahead of adding more non-atm components to the client (gdas). The new policies are:

• Client repos have to gather their YAMLs into directories: model, observations, observation_chronicle and algorithm. No directories are allowed outside of those names.
• Client YAML files in apps/<client>/model/<component> should begin with component. I.e. instead of geometry.yaml they should be atmosphere_geoemtry.yaml. This makes sure that there are no duplicate YAML files between e.g. atmosphere and marine, which could cause problems down the road in a coupling world.
• Templated client YAML files in apps/<client>/model/<component> should use template keys that are unique to that component, enforced by the keys having to take the form {{<component>_key}}.
• Model YAMLs should not use any YAML anchors. This could cause problems when YAMLs get combined if anchors are not unique. Since JCB avoid a lot of duplicate YAML writing, anchors aren't really needed anyway for the 'model' YAMLs.
• Obs YAML files are allowed to use anchors but they have to be unique to that YAML file and the anchor signature has to begin with &{observation_from_jcb} to assert uniqueness.

These policies are mostly designed to alleviate potential problems associated with having several model components in the same config file, for example when coupling. The policies are set now, despite not being needed in the immediate because it's much easier to do so now. Policies can always be revisited later if needed.

Companion PRs in jcb-gdas and jib-algorithms:

• Companion PR to NOAA-EMC/jcb/pull/7 jcb-gdas#15
• Companion PR to NOAA-EMC/jcb/pull/7 jcb-algorithms#2

[RussTreadon-NOAA]

Approve.

[RussTreadon-NOAA]

g-w PR #2665 removes jcb from g-w. Given this, it seems we can close this PR. Is this correct @danholdaway?

[danholdaway]

@RussTreadon-NOAA after jcb moves to GDASapp we can take the change in this PR but into GDASapp.

[RussTreadon-NOAA]

@CoryMartin-NOAA , I am rerunning the failed JCB tests for various python versions because the first round of tests failed after hitting what appears to be a wall clock limit. The current round of tests appears similarly stuck. I'll let 'em run but I suspect I'll get multiple fails again. If this happens, any suggestions as to how to work around this?

[CoryMartin-NOAA]

@RussTreadon-NOAA do you have a log file or something I can look at? I would think anything related to JCB should finish very quickly, so something strange must be going on.

[CoryMartin-NOAA]

@RussTreadon-NOAA or are you talking about the GitHub actions?

[RussTreadon-NOAA]

@RussTreadon-NOAA or are you talking about the GitHub actions?

Yes, @CoryMartin-NOAA, I am referring to the github actions. They appear to be hung. This is what happened on the previous run.

[CoryMartin-NOAA]

Do you see this? Or do only I have the "destructive power"? Looks like I can bypass it.

[RussTreadon-NOAA]

@CoryMartin-NOAA: Yes, I see the same Merge without waiting checkbox. I am reluctant to bypass protections since I am not sure if the failed tests indicated a problem with the PR (not acceptable) or something strange with actions (acceptable).

[CoryMartin-NOAA]

It seems like it is a GitHub actions issue. Can we maybe try running JCB ctests on HPC using this branch? (I've never done this before)

[CoryMartin-NOAA]

I manually checked out this branch on Hera, ran the commands in the CI, and all 23 tests pass. I'm going to merge and if this comes up again, we will identify and fix why the GitHub Actions are timing out.