[FEA] Expand RMM benchmarking #2385

RMM has some C++ benchmarks in cpp/benchmarks/, but they are mostly standalone microbenchmarks. CI builds them, but does not execute them to verify they are runnable. Here are some areas we might be able to improve the benchmark suite:

Add benchmark smoke tests

Register very small benchmark invocations as CTest tests or CI smoke jobs to ensure executables actually run, parse arguments, and don’t crash. Keep these separate from performance-regression checks.

Refactor from GBenchmark to NVBench to standardize benchmark methodology

• Establish common benchmark patterns for memory-resource factory selection (currently repeated in a few places), CUDA event timing, warmup, output counters, environment reporting, common CLI options.
• Use CUDA event timing for async CUDA work, and make sync costs explicit when intentionally measured.

Broaden memory-resource coverage

• Current benchmarks cover resources like cuda, cuda_async, pool, arena, binning, and managed in some places, but coverage is inconsistent. Add focused benchmarks for:
  • Comparisons between RMM resources and their closest CCCL resource equivalents (which may help us find differences in default options)
  • cuda_async_managed_memory_resource (we want to replace this with the CCCL equivalent)
  • statistics_resource_adaptor, tracking_resource_adaptor -- want to track overhead costs
  • prefetch_resource_adaptor -- measure performance with/without prefetching
  • pinned and system host resources where supported
    • Especially cudaHostAlloc vs. a pinned cudaMemPool_t

Improve replay benchmarking

• The replay benchmark currently rejects non-default streams. Supporting real stream IDs and stream ordering would make it much more representative.
• Add a small set of checked-in synthetic trace fixtures plus optional larger RAPIDS workload traces, possibly a TPC-H derived workload from Velox-cuDF.
• Report richer metrics: ops/sec, peak live bytes, allocation failures, upstream allocations, fragmentation-like indicators.

Add realistic workload suites

Beyond random allocations, add stable workload shapes that model actual users:

• small allocation churn
• mixed small/large allocations
• long-lived plus short-lived allocations
• cross-stream allocate/free
• multithreaded allocation pressure
• OOM/failure-callback paths
• device_buffer / device_uvector lifecycle-heavy workflows
  As noted above, these could be modeled with TPC-H derived workloads.

Add Python-level benchmarks

This is probably low priority, as most intensive RMM work happens in C++. There does not appear to be a Python benchmark suite. We could add benchmarks for:

• rmm.DeviceBuffer
• Python memory-resource creation/switching
• pylibrmm wrapper overhead
• Numba/CuPy allocator integration paths
  • Measuring integration overhead is probably one of the more useful things to do as we are rethinking the Python API for integration with other libraries
• logging/statistics overhead from Python

Improve documentation

Add a dedicated benchmark doc with:

• build command: build-all -DBUILD_BENCHMARKS=ON for devcontainers, something else for build.sh (?)
• executable locations under cpp/build/latest/gbenchmarks/
• example invocations
• JSON output examples
• recommended flags for reproducible local runs
• guidance on interpreting results