Support pandas copy-on-write behaviour

[dcherian]

• Closes Get ready for pandas 3 copy-on-write #8843
• Tests added

import numpy as np
import pandas as pd

pd.set_option("mode.copy_on_write", True)

from xarray.core.variable import _possibly_convert_objects

string_var = np.array(["a", "bc", "def"], dtype=object)
datetime_var = np.array(
    ["2019-01-01", "2019-01-02", "2019-01-03"], dtype="datetime64[ns]"
)
assert _possibly_convert_objects(string_var).flags.writeable
assert _possibly_convert_objects(datetime_var).flags.writeable

The core issue is that we now get read-only arrays back from pandas here:

xarray/xarray/core/variable.py

Lines 197 to 212 in fbcac76

	def _possibly_convert_objects(values):
	"""Convert arrays of datetime.datetime and datetime.timedelta objects into
	datetime64 and timedelta64, according to the pandas convention. For the time
	being, convert any non-nanosecond precision DatetimeIndex or TimedeltaIndex
	objects to nanosecond precision. While pandas is relaxing this in version
	2.0.0, in xarray we will need to make sure we are ready to handle
	non-nanosecond precision datetimes or timedeltas in our code before allowing
	such values to pass through unchanged. Converting to nanosecond precision
	through pandas.Series objects ensures that datetimes and timedeltas are
	within the valid date range for ns precision, as pandas will raise an error
	if they are not.
	"""
	as_series = pd.Series(values.ravel(), copy=False)
	if as_series.dtype.kind in "mM":
	as_series = _as_nanosecond_precision(as_series)
	return np.asarray(as_series).reshape(values.shape)

@phofl is this expected?

[phofl]

Yes, pandas now avoids copies wherever possible, meaning that an inplace modification can modify an arbitrary number of pandas objects if done outside of pandas. That's why we return read only things (same as you would get now if you have arrow arrays). You can either copy or reset the flag manually if you want to get rid of that

[dcherian]

Merging so we can get more useful upstream failure reports.