Add Rails cache store instrumentation filter

[marcotc]

What does this PR do?

This PR introduces a new :cache_store configuration option to the ActiveSupport integration. This option allows users to specify which cache stores should be instrumented by Datadog tracing.

Motivation:

This is important for very fast backends, like MemoryStore, which might not provide useful spans.

Change log entry
Yes. Add :cache_store option to ActiveSupport integration to allow tracing only specified cache backends.

Additional Notes:

• The option accepts both strings and symbols (e.g., ['file_store', :memory_store]).
• The default remains unchanged: all cache stores are traced unless this option is set.

How to test the change?

• Run the test suite, especially the integration tests for ActiveSupport cache instrumentation.
• Tests cover scenarios where :cache_store includes, excludes, or is unset for various backends.
• Manual validation: configure Datadog.configure { |c| c.tracing.instrument :active_support, cache_store: [:file_store] } and verify that only the specified store is traced.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.53%. Comparing base (de32d48) to head (2516895).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4693      +/-   ##
==========================================
+ Coverage   97.52%   97.53%   +0.01%     
==========================================
  Files        1484     1484              
  Lines       88624    88660      +36     
  Branches     4598     4602       +4     
==========================================
+ Hits        86431    86475      +44     
+ Misses       2193     2185       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-datadog-prod-us1]

Datadog Report

Branch report: mem-store
Commit report: c1ef3f8
Test service: dd-trace-rb

✅ 0 Failed, 21505 Passed, 1298 Skipped, 4m 7.22s Total Time

[drichards-87]

Left a suggestion from Docs and approved the PR.

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-07-08 16:23:05

Comparing candidate commit 2516895 in PR branch mem-store with baseline commit de32d48 in branch master.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 42 metrics, 6 unstable metrics.

scenario:tracing - Propagation - Trace Context

• 🟥 throughput [-4073.598op/s; -3966.631op/s] or [-10.971%; -10.683%]

[p-datadog]

Is the customer-supplied array duped during assignment? Otherwise this would mutate their data.

[p-datadog]

This does mutate customer-supplied array:

irb(main):022> stores=[:foo]
=> [:foo]
irb(main):023> Datadog.configure { |c| c.tracing.instrument :active_support, cache_store: stores }
# ...
irb(main):024> stores
=> ["foo"]

[delner]

Overall looks fine to me, but one suggestion for the configuration option that may be an improvement.