Use CDEPS inline stream functionality if driver is CMEPS

[mvertens]

Description of changes:

When the driver is nuopc - this PR brings in the CDEPS inline stream functionality now to ingest ndep, and ecosys forcing data alone with all other forcing data that was was previously using the cpl7 data model functionality. To do this:

1. separate copies of strdata_interface_mod.F90 were created in drivers/nuopc and drivers/mct
2. new routines were added to strdata_interface_mod to output either a 1d or 2d stream_data array. This was needed since explicit usage of mct attribute vectors cannot be used in ecosys_forcing_mod or any other non cap code.
3. ESMF has a restriction in that an ESMF_Field cannot have two field entries with the same name. As a result new forcing data was created - so the following namelist restore_data_file_varnames = 'PO4','NO3','SiO3','O2','ALK','ALK' is now restore_data_file_varnames = 'PO4','NO3','SiO3','O2','ALK','ALK_ALT_CO2' and new forcing files have been created in the namelist_defaults.xml file. Its important to point out that with the new cdeps functionality you would not need to have separate forcing files but could do online interpolation from just one forcing file.

Testing:

Starting with a beta08 sandbox - the following tests were run. For each category both the new code and the original code were compared. In both cases bfb results were produced for both 1. and 2.

1. ./create_newcase --run-unsupported --compset GOMIPECOIAF --driver mct --res T62_g37 --case $CASEROOT
2. ./create_newcase --run-unsupported --compset GOMIPECOIAF --driver nuopc --res T62_g37 --case $CASEROOT

NOTE: a cdeps update will also be needed - I am in the processing of creating that right now and will document this here. @klindsay28 @mnlevy1981 - please described other tests that would be good to carry out for this PR.

The tests I ran are currently in the following directories on cheyenne:

/glade/mvertens/pop_cdeps1/ - ran with cesm2_3_beta08, cdeps0.12.43 and this PR
/glade/mvertens/pop_cdeps0/ - ran with cesm2_3_beta08, cdeps0.12.43
/glade/mvertens/pop_cdeps1_mct/ - ran with cesm2_3_beta08 and this PR
/glade/mvertens/pop_cdeps0_mct/ - ran with cesm2_3_beta08

Test case/suite: aux_pop_MARBL Test status: verified that testst are bfb with cesm_pop_2_1_20220322 (using the cesm2_3_alpha12b checkout)

Fixes: None

User interface (namelist or namelist defaults) changes? namelist default changes for ecosys forcing files (see above)

[mvertens]

@mnlevy1981 - I'm doing some retesting and having problems get the mct to be bfb. So please hold off looking at this until I resolve this.

[mvertens]

@mnlevy1981 - never mind - I figured it out. I was comparing the wrong things.

[mvertens]

@mnlevy1981 - I have updated the comments to point out my testing directories.

[mnlevy1981]

Also, could you please verify that this is bit-for-bit with aux_pop_MARBL? I don't think we test any of the shr_stream inputs with that test list (we should fix that in a different PR), but it would still be a good sanity check.

[mvertens]

@mnlevy1981 @klindsay28 - what you are suggesting is going to take considerably more work that what I have in place. First - there is only one stream right now that reads in all of the variables - and that is for sdat. The inline functionality in both cpl7 data models and nuopc only supports one stream for in line fine usage. This stream then contains ALL of these variables. What you are suggesting would be that we would need two stream data types for nuopc - and one of those would have a duplicate name. Frankly, I see this as giving rise to a much more fragile implementation than what I have done now. What is the drawback with what I have done? In fact because you can now do regridding on the fly - you only need one forcing file - not a separate one for gx3v7 and one for gx1v7 etc. I'm happy to talk about this in a call if that would help.

[mvertens]

@mnlevy1981 @klindsay28 - I believe I misunderstood the comment @mnlevy1981. Sorry about that. It would help me to have a quick meeting tomorrow morning to sort this out. I think I really only need to meet with @mnlevy1981 - but I've included @klindsay28 as well. Hopefully we can sort this out pretty quickly. Also - I will verify if this is bfb with aux_pop_MARBL.

[mvertens]

@mlevy - @jedwards4b and I are working to remove all references to MCT when running with CMEPS/CDEPS. This is the key piece of code that needs to be updated in order to move ahead with this. I believe I have addressed the points you brought up.

[jedwards4b]

@mnlevy1981 thanks - currently all cases still build mct because until we remove it here and a few more places it's still needed. This PR is one of the last required steps to remove it from the build.