[FEA] Zero-out potentially non-zero self-distances

[jpintar]

I'm not entirely certain that this actually qualifies as a bug (as opposed to merely a limitation), and even less certain that it qualifies as a rapids_singlecell bug instead of a cuML one, but it is an undesirable behaviour.

For some metrics (e.g. cosine or correlation), cuML (v25.08) can return non-zero self-distances:

import cupy as cp
import cuml

rng = cp.random.default_rng(1234)
arr = rng.standard_normal(size=(5000, 50))

nn_obj = cuml.neighbors.NearestNeighbors(n_neighbors=30, algorithm='brute', metric='cosine')
nn_obj.fit(arr)
distances, neighbors = nn_obj.kneighbors(arr, n_neighbors=30, return_distance=True)

distances[:, 0].max()  # != 0; ~5e-07 in my tests on an H100

Obviously, this will affect downstream calculations, such as UMAP connectivities. Would it make sense to actively zero out self-distances after they're calculated here? I can't see a downside to inserting knn_dist[:, 0] = 0.0, but maybe I'm missing something...

[Intron7]

This is sadly not a bug but a fp32 inherited issue with calculating the distance in parallel. This is also upstream in cuml. I could look into setting those to 0 within rsc.

[jpintar]

I've updated the title and tried changing the label from bug to enhancement, but I don't think I can do the latter. If you want, I can make a PR for zeroing out the distances.