Replace cudaMemcpyAsync with cudaMemcpyBatchAsync to avoid locking

[PointKernel]

This PR switches from cudaMemcpyAsync to cudaMemcpyBatchAsync to eliminate a performance regression caused by driver-side locking in the legacy memcpy path. Using the new batch-async API removes that locking overhead and restores the expected performance.

[sleeepyjack]

LGTM
Could you share some details offline on why this fix is needed?

[PointKernel]

LGTM Could you share some details offline on why this fix is needed?

I’ve expanded the PR description with more context on the issue. In short, cudaMemcpyAsync incurs a costly driver lock when used across multiple streams, which leads to a noticeable performance hit. Switching to the new batch async API removes this locking behavior and resolves the regression.

[bdice]

The symbol cudaMemcpyBatchAsync exists for CUDA 12.8+ but this won't work with older CUDA 12 releases. We don't see this in cuCollections CI because it doesn't test minor version compatibility (cudf's CI builds with 12.9 and runs tests with 12.2).

@PointKernel and I discussed possible workarounds that would support CUDA 12.8+. All involve checking for and using the driver API cuMemcpyBatchAsync instead of the runtime API.

• We might be able to use cudaGetDriverEntryPoint (deprecated in CUDA 13.0) to get the driver symbol for cuMemcpyBatchAsync and use that, but I think there are some sharp edges with this approach which led to the introduction of cudaGetDriverEntryPointByVersion.
  • We can't use cudaGetDriverEntryPointByVersion because it requires CUDA 12.5+, which kind of defeats the purpose of supporting CUDA < 12.8.
• CCCL has a somewhat complex solution for dlopen'ing the driver and getting cuProcGetAddress, which we could then use to check for cuMemcpyBatchAsync support. This definitely works but it's a lot of work to get right.

For now, we concluded it's easiest to just require CUDA 13, by using the condition on #if CUDART_VERSION > 13000. For CUDA 12.8 and 12.9, we would just use cudaMemcpyAsync as in the current state.

I plan to adopt the same solution for rapidsai/cudf#20800 until we can invest the additional engineering time to support CUDA 12.8-12.9.

[bdice]

Thanks! Looks good (though I lack approval power).