[WIP] Introduce CuVS resource manager

[narangvivek10]

We have, until now, allowed for the indexing threads to attempt to build indexes on the GPU as and when they are ready. On a GPU with enough resources, dataset size, combined with the indexing pattern, like when a flush happens, etc., this may not seem to be a problem. In tighter conditions, however, and with relatively fewer resources and a large dataset, we may end up with the GPU resources running out, resulting in OOM situations.

I am introducing a CuvsResourcesManager based approach. With a finite number of ManagedCuVSResources in a pool and active monitoring of the available device memory, the requesting threads are allowed to submit requests in a controlled fashion based on resource availability by acquiring resources and releasing them when finished. Once this approach is rolled out to the Index and search on the GPU API as well, the ThreadLocalCuVSResourcesProvider based approach will be retired.

Summary of changes:

• Introduce CuvsResourcesManager
• Replace CuvsResourcesManager usage in the CAGRA->HNSW APIs with the prior ThreadLocalCuVSResourcesProvider based impl.
• Cleanup: remove CuVSProvider classes as they are redundant, as we can directly use the one available in cuvs-java, instead.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[narangvivek10]

/ok to test f7ba116

[narangvivek10]

/ok to test 5d331d9

[narangvivek10]

Below is the summary of a subset of test runs to evaluate how the peak memory estimations are performing and what we observe in reality with segment sizes ranging from 100K to 20M vectors.