feat(redisotel): add WithSkipSpanIfNotRecording option

[thani-ath-nain]

This PR was motivated by #3760 and addresses it by adding an option to skip span recording, which makes the change backward compatible.

---

Note

Low Risk
Low risk and opt-in: only changes tracing behavior when WithSkipSpanIfNotRecording(true) is set, reducing unnecessary span creation when tracing is disabled or sampled out.

Overview
Adds a new tracing option, WithSkipSpanIfNotRecording, that prevents redisotel hooks from starting redis.dial, command, and pipeline spans when the span in the incoming context is not recording.

Includes comprehensive tests covering dial/process/pipeline behavior for no parent span, sampled-out parents, and preserving the existing default behavior when the option is disabled.

^{Reviewed by Cursor Bugbot for commit c6910b2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.

[thani-ath-nain]

@Jesse-Bonfire @wzy9607 @htemelski-oss can you please review this PR

[thani-ath-nain]

CI failing due to code that is unrelated to my changes:

=== RUN   TestDialConn_DialTimeoutDisabled_DoesNotSetDeadline
    dial_conn_retry_test.go:174: expected 1 dial attempt, got 2
--- FAIL: TestDialConn_DialTimeoutDisabled_DoesNotSetDeadline (0.00s)

[ndyakov]

@thani-ath-nain, we do have two flaky tests that are the reason for the failing CI. I am aware of those

[ndyakov]

Code looks good to me, will let the community decide if we would like to merge this.

[thani-ath-nain]

Addressed Cursor’s review by applying WithSkipSpanIfNotRecording to DialHook too and added tests. Verified with go test ./... in extra/redisotel the remaining CI issue is still the known unrelated flaky test. Can a maintainer please review and merge this?

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit c6910b2. Configure here.}

[thani-ath-nain]

@ndyakov Thank you for the review! I appreciate you acknowledging the flaky test issue. Since the code has your approval, would you be able to tag a few other maintainers who might have context on the tracing/telemetry parts of go-redis? I'd love to get additional eyes on this to help the community decide. Alternatively, if there are specific concerns or discussion points that need to be addressed before merging, I'm happy to provide more context or make adjustments. The feature is backward-compatible (opt-in only) and addresses a real performance concern; happy to elaborate on the use case if helpful.