site-level mass flux accounting part 2

[rgknox]

Description:

This PR seeks to generate more consistency with how we track and restart some site-level mass fluxes. These mass fluxes are used for multiple purposes: run-time mass balance checks, history diagnostics and boundary conditions. So these fluxes needed a little attention in how they are used.

This PR is based on and should follow: #1448

Collaborators:

@glemieux @ckoven

Expectation of Answer Changes:

No answer changes, but it should fix restart errors with E3SM mass_balance_error diagnostics.

Checklist

If this is your first time contributing, please read the CONTRIBUTING document.

All checklist items must be checked to enable merging this pull request:

Contributor

• The in-code documentation has been updated with descriptive comments
• The documentation has been assessed to determine if updates are necessary

Integrator

• FATES PASS/FAIL regression tests were run
• Evaluation of test results for answer changes was performed and results provided
• FATES-CLM6 Code Freeze: satellite phenology regression tests are b4b

If satellite phenology regressions are not b4b, please hold merge and notify the FATES development team.

Documentation

• Technical Note update:
• User's Guide update:

Test Results:

CTSM (or) E3SM (specify which) test hash-tag:

CTSM (or) E3SM (specify which) baseline hash-tag:

FATES baseline hash-tag:

Test Output:

[rgknox]

Making a note that we should add a comment units fix originally posted #1474