[release/9.0] Redis distributed cache: add HybridCache usage signal

[github-actions]

Backport of #59543 to release/9.0

/cc @mgravell

Redis distributed cache: add HybridCache usage signal

Add connection usage marker for HybridCache to improve connection metadata / visibility.

Description

{Detail}

We already use "DC" and "OC" markers on RESP connections to provide a non-intrusive signal that Distributed Cache and Output Cache are being used; since HybridCache is a feature on top of IDistributedCache, here we add an additional "HC" token to indicate that a RESP connection is being used for HybridCache.

We do this by using IServiceProvider (changing the internal RedisCacheImpl(...) constructors) to detect HybridCache as a service. We don't need it to be the official HybridCache specifically (as in .AddHybridCache()) - just that a HybridCache exists. There are no public API or dependency changes required.

Customer Impact

Improves connection metadata / visibility, i.e. we know what different Redis connections are being used for.

No API changes. Improves internal metrics.

Regression?

• Yes
• No

[If yes, specify the version the behavior has regressed from]

Risk

• High
• Medium
• Low

[Justify the selection above]

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

---

When servicing release/2.1

• Make necessary changes in eng/PatchConfig.props

[jodydonetti]

Hi, how does this signal tweak the connection?
Is there something else 3rd party HybridCache implementers should be aware of?

For example with FusionCache it's totally possible to use RedisCache in our apps without being forced to use that as the L2 of FusionCache, even when using it via the HybridCache adapter: in this case the checks I see here would not be technically "correct".

Can a false detection create problems?

Thanks.

[mgravell]

Tactics requested; approved 2025-01-24

[mgravell]

Test failures seem to be build/SDK related:

Xunit.Sdk.EqualException: Assert.Equal() Failure
↓ (pos 4)
Expected: 9.0.0
Actual: 9.0.1

[mgravell]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).