Add ability to coldstart or use a different restart file for the RUN_TYPE=hybrid option for cesm-coupling

[ekluzek]

The control file determines the starutp file for mizuRoute to start from (fname_state_in). In the hybrid and branch case (setting of the XML variable RUN_TYPE), though it ignores this variable and uses what's set in the REF XML variables.

There are times when you want to override this behavior, and you want to have the other models do a restart from existing restarts, but you want to provide a different one for mizuRoute and/or do a coldstart for mizuRoute.

I think the way to do this would be to either:

1.) Add an option(s) to the control file

2.) Add an XML option(s) for mizuRoute for cesm-coupling cases

Since, in standalone cases the fname_state_in is always used -- this really only applies to the cesm-coupled case. So it seems like the second one makes the most sense. So an XML variable for mizuRoiute could be added with a name like "USE_CONTROL_FILE_FOR_STARTUP_FILE" or "OVERRIDE_REF_CASE_STARTUP_FILE".

Definition of done:

• Write a warning to the user when the user has set fname_state_in and it's being overridden and to say they can use the XML variable to change this behavior
• Decide if this should be done for both hybrid AND branch (since branch is usually used to have an exact restart I think the answer is NO for branch)
• Figure out how this should be done, and define what the variable names should be (no names, just use from control file if wet)
• Add an XML option to cime_config/config_component.xml (won't do this)
• Add a testcase for this in the testmods and testlist
• Add the handling of it in cime_config/buildnml
• Make sure this works in the test list

[ekluzek]

A first naming convention to figure out is -- what to call any mizuRoute variables. Most components use the name of the model as a prefix to be used. So for example CLM_ or DATM_ or MOSART_*. For mizuRoute this could be:

MIZUROUTE_*

or say...

MIZU_*

I advocate the second just to make it shorter.

[ekluzek]

I also realized that the override for the user supplied value in the control file -- should also be written out as a warning to the user. And it can say to override doing this use the XML variable to change the behavior.

[ekluzek]

Talking with @nmizukami we thought we shouldn't have an extra variable to control doing the override. But, let's just believe that if the user set the fname_state_in to something that's not "empty" -- it should be used. This is a simpler way as well.

[ekluzek]

If/when we do add MIZUROUTE_* config_component varialbes, @nmizukami advocates for the full name for consistency.