[EXPERIMENTAL] Exploring mdarray APIs

[achirkin]

Implementing various container types fully within mdarray/mdspan framework.

• shared_device_mdarray: mdarray with ref-counting container policy adds capability to share mdarrays by copying them by value
• compressed_mdarray / compressed_mdspan: several implementations of mdarrays and mdspans that keep the codebooks alongside the data

[cjnolet]

I’ll be honest, I’m not sure how this improves upon the datasets API that we have implemented in cuVS. There’s a very clear separation of concerns here that’s needed between mdspan/mdarray (the matrix-level abstractions) and the notion of inputs to various algorithms. I also don’t think we should be muddying the waters here by putting implementation-specific details from downstream libraries in raft itself (like quantization, etc..).

Can you improve the description here to explain why this is needed over the datasets api? We plan to merge the datasets api into 26.06 and use that going forward, unless there is an extremely compelling reason that some other API is superior.

[achirkin]

Hi Corey, thanks for the feedback! Sure, I will update the description with the motivation and use-cases. I've just realized the mdspan/mdarray API is extremely flexible as-is to the extent that they alone may be able to cover all spectrum of raft/cuvs data apis, like bit-packed data, all sorts of compressed representations, sparse data type etc. All that while retaining clear separation between owning/non-owning versions and optionally shared ownership semantics like in cuda::mr.
That being said, this PR is not intended to be merged - I'm just exploring what is possible to share it for future discussion (and the compressed API can surely go to cuVS if we like it).