fix: Filter out StringDType even when the backing array is not NumpyExtensionArray

[ilan-gold]

The linked issue is resolved by this PR but more broadly, the issue underlying it (letting in string dtypes that are not NumpyExtensionArray) was bound to come up at some point so this PR more comprehensively fixes that issue and tries to centralize our "whitelist"

• Closes String coords broken in pandas git tip #10553
• Tests added - nightly? somewhere?
• User visible changes (including notable bug fixes) are documented in whats-new.rst
• New functions/methods are listed in api.rst

[keewis]

I've added the run-upstream tag so it runs on all commits, but for future PRs you can also run the nightly CI by appending [test-upstream] to the first line of a commit message.

[ilan-gold]

I didn't add UNSUPPORTED_EXTENSION_ARRAY_TYPES to the new is_allowed_extension_array function because we do allow them as backing arrays to Index object, I think. Maybe should get a test?

[dcherian]

I think we should merge these checks.

[ilan-gold]

I think we need to account for internal duck array support i.e., that which allows preserving the dtype of extension array indices that are in this UNSUPPORTED_EXTENSION_ARRAY_TYPES whitelist. See the note here:

xarray/xarray/core/extension_array.py

Lines 101 to 103 in 5ce69b2

	# This does not use the UNSUPPORTED_EXTENSION_ARRAY_TYPES whitelist because
	# we do support extension arrays from datetime, for example, that need
	# duck array support internally via this class.

[dcherian]

Was that for DatetimeIndex? If so, clarifying that comment would be helpful.

[ilan-gold]

It would be for any index whose underlying array is one of the ones in UNSUPPORTED_EXTENSION_ARRAY_TYPES, so possible DatetimeIndex but also likely other ones as well

[dcherian]

Sadly these upstream failures seem related. @kmuehlbauer may be able to help reason through them

[ilan-gold]

@dcherian I think they're only related in so far as they come from pandas>3.0. I tracked down the issue and it comes from this line:

xarray/xarray/core/variable.py

Lines 215 to 216 in 5ce69b2

	as_series = pd.Series(values.ravel(), copy=False)
	result = np.asarray(as_series).reshape(values.shape)

It appears (I have no experience with this, so correct me if I'm wrong), that the "real" type is encoded in dtype("O").metadata for certain netcdf4 variables. But this dtype.metadata is not preserved after a pd.Series call. I added a fix for it, but made it a separate PR as I'd like to ensure this PR does what it advertises first

[ilan-gold]

@dcherian do you have any idea what to do about this mypy failure coming from https://github.com/pydata/xarray/pull/10559/files#diff-382db5ef1ceae5d2d63b503937f667dd7d61a3b1e579352db328c12379516151L161-L162

If I ignore it, it says the ignore is unused. If I try to ignore the specific warning raised, it says that the ignore is unnecessary. And now, if I use Any to type it, it still complains. There was a "Unsure why we get a mypy error here" which signals to me something else is going on here.