issues discovered by the all-but-dask CI

[keewis]

After adding the py38-all-but-dask CI in #3919, it discovered a few backend issues:

• zarr:
  • open_zarr with chunks="auto" always tries to chunk, even if dask is not available (fixed in add a CI that tests xarray with all optional dependencies but dask #3919)
  • ZarrArrayWrapper.__getitem__ incorrectly passes the indexer's tuple attribute to _arrayize_vectorized_indexer (this only happens if dask is not available) (fixed in add a CI that tests xarray with all optional dependencies but dask #3919)
  • slice indexers with negative steps get transformed incorrectly if dask is not available Fix negative slicing of Zarr arrays #8674
• rasterio:
  • calling pickle.dumps on a Dataset object returned by open_rasterio fails because a non-serializable lock was used (if dask is installed, a serializable lock is used instead)

[max-sixty]

Great finds @keewis !

Any idea why a lock is being serialized at all with a Dataset?

[keewis]

I think the lock is used to synchronize the I/O on the rasterio file, so we can't really remove it. The failing test states it is a regression test for #2121, but since then the backend code was rewritten. We'd probably need a serializable lock that does not depend on dask (I don't know much about the backend code, though)

Edit: we could vendor dask's SerializableLock, which basically wraps a threading.Lock but also makes sure to use the same lock after every pickle dumps/loads cycle.

[headtr1ck]

I think the last remaining item has been fixed by #7586, but not completely sure.

Then we could close this issue :)

[keewis]

I think we'd need to be able to remove this xfail first:

xarray/xarray/tests/test_backends.py

Lines 712 to 714 in f8127fc

	@pytest.mark.xfail(
	reason="zarr without dask handles negative steps in slices incorrectly",
	)

I didn't check, this could be xpassing right now.