Simplify memory-resource handling in Dask integration

[rjzamora]

This is a follow-up to #150

Closes #157

The goal of this PR is to simplify memory-resource creation by avoiding it in rapidsmp altogether. Since the user can just use LocalCUDACluster to deploy a Dask cluster, they can also use existing options/utilities to create a memory pool on each worker. When rapidsmp.integrations.dask.bootstrap_dask_cluster is called, each worker only needs to wrap the current memory resource in a StatisticsResourceAdaptor.

This is technically "breaking", because it removes the pool_size argument from bootstrap_dask_cluster. However, we are only using that option in rapidsai/cudf#18335 (which is still experimental - and can be easily changed).

[rjzamora]

Note: The current memory resource doesn't need to be a pool for spilling to work.

[TomAugspurger]

I think this closes #157.

Does this require that the dask-cuda worker be created with any special arguments? I think the answer is no: rmm.mr.get_current_device_resource will always return something, regardless of whether the user created the LocalCUDACluster with something like rmm_pool_size.

[rjzamora]

Does this require that the dask-cuda worker be created with any special arguments? I think the answer is no: rmm.mr.get_current_device_resource will always return something, regardless of whether the user created the LocalCUDACluster with something like rmm_pool_size.

Right - It doesn't require the user to pass in an rmm_pool_size argument, but they should do this if they want good performance.

[TomAugspurger]

In that case, it might be good to add that note to our quickstart example: https://github.com/rapidsai/rapids-multi-gpu/blob/branch-25.06/docs/source/quickstart.md#dask-cudf-example.

[rjzamora]

In that case, it might be good to add that note to our quickstart example

Good suggestion. I tweaked the code and added a brief comment.

[pentschev]

Makes sense, thanks @rjzamora .

[rjzamora]

/merge