Use 1D grid calculations in epsilon_neighborhood

[divyegala]

Closes rapidsai/cuml#5393 closes rapidsai/cuml#7676

This was necessary to bypass the limits of grid.y < 65536, as cuml passes n_rows to the n_cols dimension in the usage of this API.

[dantegd]

Looks good to me, though before approving explicitly wanted to ask if you think it'd be worth adding a explicit test to exercise this?

[divyegala]

Looks good to me, though before approving explicitly wanted to ask if you think it'd be worth adding a explicit test to exercise this?

@dantegd good idea. Will add 👍

[tarang-jain]

I see what is being done here. LGTM except possibly one minor optimization

[viclafargue]

Thanks Divye! LGTM. An alternative solution would have been to swap the x and y dimensions. The number of features divided by Policy::Mblk should rarely ever go beyond the limit of 65535. This would avoid adding an argument to the kernel and also avoid the two small instructions to get block_x and block_y back. But, I agree that the current solution may be more robust.

[divyegala]

@viclafargue That solution does not work because we cannot guarantee always that m will be passed as n. cuML itself reverses the values of m and n before calling this function, but cuVS does not expect the reversal. So if anyone else uses the API then you run into the same problem.

[divyegala]

/merge