Test updates of CCCL (thrust, cub, libcudacxx) to 2.1.0.

[bdice]

This PR tests a rapids-cmake branch with CCCL (thrust, cub, libcudacxx) updated to 2.1.0. Do not merge this PR. The changes will be merged upstream in rapids-cmake after all libraries pass CI.

[bdice]

@robertmaynard @vyasr Thrust added a dependency on libcudacxx in version 2.0.0. That means we get different behavior than I had hoped for with rapidsai/rapids-cmake#399. Specifically, Thrust is pulling in libcudacxx version 1.8.1.0 from its git submodule dependency, while I would like to pin to the latest version 2.1.0. What would you recommend doing here? Do we need to add a CMake requirement for libcudacxx before Thrust finds its own outdated submodule copy?

Before (Thrust 1.17.2):

-- CPM: adding package [email protected] (1.17.2)
-- Found Thrust: $SRC_DIR/build/_deps/thrust-src/thrust/cmake/thrust-config.cmake (found version "1.17.2.0") 
-- rapids-cmake [Thrust]: applied diff transform_iter_with_reduce_by_key.diff to fix issue: 'Support transform iterator with reduce by key [https://github.com/NVIDIA/thrust/pull/1805]'
-- rapids-cmake [Thrust]: applied diff install_rules.diff to fix issue: 'Thrust 1.X installs incorrect files [https://github.com/NVIDIA/thrust/issues/1790]'
-- Found CUB: $SRC_DIR/build/_deps/thrust-src/dependencies/cub/cub/cmake/cub-config.cmake (found suitable version "1.17.2.0", minimum required is "1.17.2.0") 

After (Thrust 2.1.0):

-- CPM: adding package [email protected] (2.1.0)
-- Found libcudacxx: $SRC_DIR/build/_deps/thrust-src/dependencies/libcudacxx/lib/cmake/libcudacxx/libcudacxx-config.cmake (found suitable version "1.8.1.0", minimum required is "1.8.0") 
-- Found Thrust: $SRC_DIR/build/_deps/thrust-src/thrust/cmake/thrust-config.cmake (found version "2.1.0.0") 
-- Found CUB: $SRC_DIR/build/_deps/thrust-src/dependencies/cub/cub/cmake/cub-config.cmake (found suitable version "2.1.0.0", minimum required is "2.1.0.0") 

[robertmaynard]

@robertmaynard @vyasr Thrust added a dependency on libcudacxx in version 2.0.0. That means we get different behavior than I had hoped for with rapidsai/rapids-cmake#399. Specifically, Thrust is pulling in libcudacxx version 1.8.1.0 from its git submodule dependency, while I would like to pin to the latest version 2.1.0. What would you recommend doing here? Do we need to add a CMake requirement for libcudacxx before Thrust finds its own outdated submodule copy?

We should update rapids-cmake/cpm/thrust.cmake to be aware of this new dependency and have it call rapids-cmake/cpm/libcudacxx.cmake before it adds thrust so we always get the expected libcudacxx version.

[bdice]

@robertmaynard I have now updated libcudacxx upstream and it appears that builds/tests are passing. I verified in the logs that Thrust/CUB/libcudacxx versions 2.1.0 are being used.

I will open testing PRs for other RAPIDS repositories.

[bdice]

Note to self: switch rmm to use fetch_rapids.cmake. That way, the logic for rapids-cmake won’t be duplicated between the C++ and Python CMakeLists.txt. https://github.com/rapidsai/cudf/blob/branch-23.10/fetch_rapids.cmake

edit: done in #1319.

[bdice]

Closing in favor of #1404.