This is an experiment, opening as a PR for discussion.

Currently only stream_ordered_memory_resource<cuda::memory_kind::device> is used as a basis. So far I've converted only cuda_memory_resource and managed_memory_resource. Obviously this is not ideal because these should really have different memory kinds. And really we should be able to use a single class with different kinds for the implementation of these two. But it's a start, and it works with our current test infrastructure.

Adding other memory kinds will result in multiple independent base classes which will require refactoring how we write MR tests so that they are not value parameterized on the MR. This is a pain because value parameterization lets us create simple factory functions for instantiating the MR, which is valuable since some MRs are multi-layered (e.g. hybrid_MR) so a simple call to the ctor is not sufficient.

Suggested roadmap to integrating cuda::memory_resource (from @jrhemstad )

• Delete device_memory_resource class
• Make all resources that currently inherit from device_memory_resource inherit from cuda::stream_ordered_memory_resource<Kind>, where in instance of cuda_memory_resource Kind is device and for pool_memory_resource Kind is a template parameter dependent on the upstream
• Throw if alignment is larger than 256 (full alignment support can be added later)
• Update all RMM interfaces that currently accept device_memory_resource* to cuda::resource_view<Props...> where Props... is a variadic type pack
• Rename device_buffer to buffer<Kind>
• Update all libcudf (and other libs) interfaces that take device_memory_resource* to resource_view<device_accessible>

Comments (from @harrism):
This is obviously incredibly invasive to RAPIDS and other dependent libraries. We need to plan how to manage that disruption and how to break up the above into separate PRs. The final step should be doable independently, however we would need to keep device_memory_resource until that is complete.