[v3] First step to generalizes ndarray and bytes

[madsbk]

This PR introduces two new classes NDBuffer and Buffer to represent the data argument between components.

Currently, we use numpy.ndarray and bytes to pass around data between components. As discussed in #1751, it would be good with a generalization of the data containers to enable other memory types.

As a first step, NDBuffer and Buffer are backed by numpy arrays. In follow-up PRs, we can discuss/implement alternative backends such as cupy arrays or pytorch tensors. The important point here is to agree on an abstraction that can facilitate a broad range of array/data types.

cc. @akshaysubr, @jakirkham

[madsbk]

This PR is ready for a new round of reviews. As @normanrz suggested, I have removed the inheritance between the two buffer classes Buffer and NDBuffer.

AsyncArray.getitem() and AsyncArray.setitem() now takes a factory function to create a buffer from a ndarray-like object. We still need a mechanism to tell codecs and stores what type of buffer they should return but let’s do that in a follow-up PR.

[normanrz]

Would it be possible to have an as_memoryview method that could be used for passing to Blosc, Gzip etc.? Would that also work without copying?

[madsbk]

An as_memoryview would work like as_numpy_array. It might involve copying data depending on what the underlying ndarray-like object the buffer represent. E.g., if self._data is a cupy array, we have to copy from device to host memory.

[normanrz]

I just found the method name as_ndarray_like confusing because it actually returns a wrapped 1d byte array

[madsbk]

Good point, Buffer is now backed by ArrayLike: 3854bec

For now, both ArrayLike and NDArrayLike are alias of np.ndarray.

[normanrz]

Sweet!