String coordinates being promoted to a cube in 3.16

[stephenworsley]

Behaviour change in 3.16:

When loading a NetCDF file which had a season dimension referring to a string type variable, this used to load as an AuxCoord on the cube, in 3.16 it loads as a separate cube.

[pp-mo]

We do have a local file to test this, but it's not shareable.
The key points though are seen in a file like this (CDL) ...

netcdf ... {
dimensions:
	season = 4 ;
	grid_latitude = 562 ;
	grid_longitude = 420 ;
variables:
	float threshold(season, grid_latitude, grid_longitude) ;
	string season(season) ;
}

The 'season' variable "should" load as an an aux-coord (since as strings it doesn't count as a DimCoord (aka CF 'coordinate').

In Iris 3.15
is it first categorised by cf.py as a CFCoordinateVariable, it fails to make a DimCoord due to its type, and is 'gracefully' demoted to an AuxCoord

In Iris 3.16
it now fails to be categorised as a CFCoordinateVariable, since we changed the detection of string types for that.
Under CF rules, I believe it should also fail to be a CFAuxiliaryCoordinateVariable, due to type, and should instead become a CFLabelVariable.
But unfortunately that isn't happening due to the way that those 2 classes do the type testing
-- needs fixing

The upshot, for now, is that it falls back to being a CFDataVariable + loads as a separate cube -- and the other cubes no longer have it as an AuxCoord.

[pp-mo]

From discussion with @trexfeathers.
In the "old world", this variable appears as an attached AuxCoord, because cf.py categorises it as a CF (dimension) "coordinate".
And when Iris load fails to create a DimCoord (because non-numeric), it falls back on making it into an AuxCoord instead.

In this case, that behaviour looks useful -- because 'season' "looks like" it should be a dimension coord.
But strictly, that is wrong according to CF rules, and what Iris now does is "right".
We probably need a note about that in the whatsnew.

[ESadek-MO]

From @SciTools/peloton: Could potentially be solved by the ongoing work at #3726. Essentially, this would give users the ability to do it the "wrong but useful" way, as opposed to the "correct but unhelpful" way, without undermining the integrity of Iris.