[develop] Integrate jinja-templated workflow and add some rrfs workflow files.

[danielabdi-noaa]

DESCRIPTION OF CHANGES:

This PR extends upon work done in PR #701 to integrate jinja support to config and workflow files. Enabling jinja in config/workflow files turned out to be not as straight forward as I expected. Some things that complicated things include

• We relied on extend_yaml that only renders jinja-templates in "values" of dictionaries. While this works just fine, we
  may need jinja-templating throughout the config files e.g. if-conditions
• Some newly added filters like include load a yaml config file and do not work when it is templated. The solution I used for this is to just copy/paste the files to be included. The jinja {% include %} construct could potentially used but I haven't investigated further
• Rendering for "values" in extend_yaml has a dependency chain because it is referring to the same dictionary to update values. To render other templates, you will have to provide a secondary dictionary.
• Anchors used in the new workflow files need to be unique because they may not be expanded and eliminated before filling up jinja templates
• We need to construct the config files (default/machine/user) before constructing workflow config files, since the latter use them. So setup.py is modified to construct config files before workfow files.

To test this functionality, I have added the RRFS workflow jinja-templated throughout. Where I think this may come in handly is in dependencies where a lot of jinja-template d code is used. The jinja-templated workflow files mirror that of the xml file.
I tested this setup in PR #647 where none of the RRFS tasks are added, so while it will generate the workflow, it needs to be tested/fixed as each task goes in.

This PR has modifications from PR#701 and PR#647 since it needs both for a successful RRFS_Dev workflow generation.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

TESTS CONDUCTED:

• hera.intel
• orion.intel
• cheyenne.intel
• cheyenne.gnu
• gaea.intel
• jet.intel
• wcoss2.intel
• NOAA Cloud (indicate which platform)
• Jenkins
• fundamental test suite
• comprehensive tests (specify which if a subset was used)

DEPENDENCIES:

DOCUMENTATION:

ISSUE:

CHECKLIST

• My code follows the style guidelines in the Contributor's Guide
• I have performed a self-review of my own code using the Code Reviewer's Guide
• I have commented my code, particularly in hard-to-understand areas
• My changes need updates to the documentation. I have made corresponding changes to the documentation
• My changes do not require updates to the documentation (explain).
• My changes generate no new warnings
• New and existing tests pass with my changes
• Any dependent changes have been merged and published

LABELS (optional):

A Code Manager needs to add the following labels to this PR:

• Work In Progress
• bug
• enhancement
• documentation
• release
• high priority
• run_ci
• run_we2e_fundamental_tests
• run_we2e_comprehensive_tests
• Needs Cheyenne test
• Needs Jet test
• Needs Hera test
• Needs Orion test
• help wanted

CONTRIBUTORS (optional):

[christinaholtNOAA]

I do not think this will, in general work. We should work offline to discuss the design pattern and how new workflows should and can be added with the existing tools. The behavior of the existing tool will get us the full flexibility we need for RRFS.

Specifically, putting these switches in convolutes the process of building a workflow based on a configuration from component pieces. For example, if you want to modify cycles, it should be done by config file, not a switch defined in the workflow. Let me find some time to have a more thorough discussion about the options and why I don't think we want to go this direction.

[danielabdi-noaa]

@christinaholtNOAA Ok I will cose this PR.