Define common-metadata operations on split attribute dictionaries.

[pp-mo]

WIP
just testing
provisional changes to common-metadata to accommodate split attribute dictionaries

No new function yet -- just to see if it breaks any existing tests
Will need additional tests for how this actually functions with split-attr testcases

EDIT: this actually works now, and should be good, subject to first merging SciTools#5410 and rebasing/retargetting this as required.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (splitattrs_ncsave_redo@cbd7167). Click here to learn what that means.
The diff coverage is n/a.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@                    Coverage Diff                    @@
##             splitattrs_ncsave_redo      #77   +/-   ##
=========================================================
  Coverage                          ?   89.44%           
=========================================================
  Files                             ?       89           
  Lines                             ?    22590           
  Branches                          ?     5422           
=========================================================
  Hits                              ?    20205           
  Misses                            ?     1639           
  Partials                          ?      746           

[pp-mo]

Note:

legacy tests do pass ! 👍
remaining:

• tests
• decide whether the lenient cases should have some more split-specific behaviour, and implement if needed

[pp-mo]

Hmm, we are not done with this, as seen in doc-tests failures.
I think because we need to allow for operations between different metadata classes ?
I had thought that the common metadata code converted inputs to same type to avoid that -- need to look again.

[pp-mo]

Hmm, we are not done with this, as seen in doc-tests failures. I think because we need to allow for operations between different metadata classes ? I had thought that the common metadata code converted inputs to same type to avoid that -- need to look again.

Ok I think the latest commit fixes it.

The logic here is that different Metadata types may not be combined in operations.
But that doesn't mean that all CubeMetadata.attributes must be a CubeAttrsDict. Naturally not, since the .difference operation produces a CubeMetdata whose .attributes is a pair(tuple).
So, the content of the "attributes" property in a Cube is controlled, but CubeMetadata objects themselves can be more various.

By "promoting" left+right to split-dicts where required, I think this gives the correct behaviour.
There are no specific tests for this usage (but the usage here in the docs is putting a regular dict into a CubeMetadata -- this is the doctest that failed).
However, I don't think we need to add any, since this is rather a corner-case : because actual Cube.attributes are always constrained to be a CubeAttrsDict.