Generic linalg::map

[achirkin]

Update the implementation behind raft::linalg::map and raft::linalg::map_offset to allow multiple inputs and optional index.

Originally, this is a part of the effort to reduce the latency of ivf-pq search. The new implementation replaces several helpers, which have been using thrust; at the moment, raft uses a thrust policy that occasionally inserts extra cudaStreamSynchronize, and this negatively affects the latency on small inputs.

The new implementation is generic enough to replace many raft's utility functions. It uses vectorized load/stores if possible, which improves performance.

This is the second take on the PR #1329 that keeps the deprecated map_k function, which is used in cuml.

[cjnolet]

/merge

[MatthiasKohl]

@cjnolet This PR just broke our builds in cugraph-ops because it uses a host constexpr function (std::min) in device code.
The relevant compiler flag is mentioned here: https://github.com/rapidsai/raft/blob/branch-23.04/docs/source/build.md#using-raft-in-downstream-projects
but I was just wondering: is there some list of compiler flags that's required to build RAFT?
It's possible that we're missing other flags like this one

[MatthiasKohl]

@achirkin @cjnolet IIUC, this PR breaks at least the API semantics of raft::linalg::writeOnlyUnaryOp because the Lambda now takes as first input a reference to the output that should be written to the output pointer, whereas previously it took as first input the output pointer.
This was also documented clearly at the API level here :

raft/cpp/include/raft/linalg/unary_op.cuh

Lines 60 to 62 in 79e1ce8

	* @tparam Lambda Device lambda performing the actual operation, with the signature
	* `void func(OutType* outLocationOffset, IdxType idx);`
	* where outLocationOffset will be out + idx.

Semantically, the new function doesn't do the same thing at all, and it took me a lot of time to trace our issues in CI to this.

I know this PR is marked as breaking but it would be great that if we change the semantics of very generic functions like these, we notify others ahead of time so that we can check whether we make use of those semantics (that were guaranteed before, see the docs linked above !).

Thanks

[cjnolet]

@MatthiasKohl I do apologize for this. I did a quick verification to make sure this wouldn't break any other repositories downstream but I admit I did not check cugraph-ops (and am honestly surprised to see that it's being used there).

Would it help if we went ahead and backed out the change for the write only unary op for now? Please note that we are planning to deprecate the writeOnlyUnaryOp function very soon in favor of map_offset anyways, unless there's any pressing need to keep the original semantics as-is.

[MatthiasKohl]

@cjnolet I already updated our codes now, so everything should still work correctly with the next PR being merged on our side. I don't think it's worth it to back out again, but I wasn't sure if other projects weren't affected by this.