[FEA] Separate index sorting from CAGRA graph pruning

[enp1s0]

Hi, @tfeher

The current implementation of CAGRA index pruning always sorts the input index before performing the pruning.
However, it is unnecessary when CAGRA builds the input index because the CAGRA index-building function outputs a sorted index.
On the other hand, when the index is not built by CAGRA and not sorted, the sorting process is necessary to use CAGRA pruning.
Therefore, it would be useful to make sorting optional, depending on whether the index is built by CAGRA or not.

One of the solutions for this issue is to separate the sorting process from the CAGRA pruning function and create a separate sorting function.
This would involve modifying the current prune function as follows:

template <typename IdxT = uint32_t,
          typename g_accessor =
            host_device_accessor<std::experimental::default_accessor<IdxT>, memory_type::host>>
void prune(raft::device_resources const& res,
           mdspan<IdxT, matrix_extent<IdxT>, row_major, g_accessor> knn_graph, //[in]
           raft::host_matrix_view<IdxT, IdxT, row_major> new_graph); //[out]

template <typename DataT, typename IdxT, typename accessor>
void sort_knn_graph(raft::device_resources const& res,
                     mdspan<const DataT, matrix_extent<IdxT>, row_major, accessor> dataset, // [in]
                     raft::host_matrix_view<IdxT, IdxT, row_major> knn_graph); // [in, out]

An alternative solution is to make the dataset argument std::optional and sort the index only if the argument is provided.

I prefer the approach of separating the sorting function because it can reduce the time required for compiling sorting operations during compilation when the sorting function is not used in the source code.

If there are no issues with this approach, I will modify the implementation accordingly.

[tfeher]

One of the solutions for this issue is to separate the sorting process from the CAGRA pruning function and create a separate sorting function

Thanks for creating the issue! This sounds fine to me.

Linking the tracker issue #1392