Support new cuda-python layout

[vyasr]

cuda-python 12.6.1 (11.8.4 on the CUDA 11 line) introduces a new layout and deprecates the old one. This is not considered a breaking change for them, but it is for much of RAPIDS CI where warnings are treated as errors. In the short term, the resolution is #116, which adds pinnings to avoid this problem (as well as others). Longer-term, we probably do not want to just change our imports because that would make us require only the latest versions of the package, which would be fairly constraining and could make our environments unsolveable if other libraries do not make similar updates. Instead, we will need to handle this importing conditionally to ensure that we can get what we need. Presumably this doesn't impact cimports since those would be Cython build warnings (and we are generally not blocked on those), so conditional imports should be sufficient to enable a broader range of usability.

[bdice]

I chatted with @vyasr about this offline. I would prefer for us to increase our lower bound of cuda-python to >=12.6.2 / >=11.8.5 to ensure we can use the new package layout (cuda.bindings), and refactor our imports accordingly. There is some risk in taking on a lower-bound that is so new, because it could constrain our ability to have consistent environments with other cuda-python consumers if other libraries have upper bounds. Hopefully by the 25.02 release, we would know if such issues exist in practice.

We can always go the route of adding backwards compatibility for older cuda-python versions (via conditional imports) later on. Using conditional imports introduces complexity and forces us into another decision (when do we drop support for "old style" cuda-python?) so I am not really eager to start with this approach. Increasing the lower bound to use the new layout also eliminates all deprecation warnings, keeping us from running into issues like rapidsai/rmm#1730.

We do occasionally use conditional imports for core dependencies like pandas and pyarrow, but I would like to avoid that in this case, especially given that RAPIDS works closely with cuda-python and can request patch releases for most regressions we find.

[vyasr]

Thanks for writing this up Bradley! On further consideration I am fine with the approach of upgrading now and reenabling older versions later.

Hopefully by the 25.02 release, we would know if such issues exist in practice. We can always go the route of adding backwards compatibility for older cuda-python versions (via conditional imports) later on.

@leofang do you have a sense of how likely this case is? Basically this boils down to a question of how many packages you are aware of that are doing from cuda.cudart import or equivalent from other modules (but not cimport; I'm only concerned with runtime Python imports) in their code bases. I don't have a good sense of how concerned we should currently be about needing to create (conda or pip) environments where packages are still relying on the old layout (which I guess just means deprecation warnings, not runtime errors) or pinning to older versions (seems unlikely). Given that the latter seems unlikely I'm pretty OK with moving forward with Bradley's proposal.