ResponseCachingMiddleware is too restrictive – IResponseCachingKeyProvider and IResponseCache should be public

[Dimoner]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

When using ResponseCachingMiddleware, I encountered several limitations that make it difficult to extend or optimize its behavior:

1. Custom Key Provider is not possible
   IResponseCachingKeyProvider is internal, so I cannot modify the key generation logic.
   I need to use a hashed key (XxHash128 with a fixed key) for security reasons (storing encrypted cache keys).
   This also allows optimizations with stackalloc and enables distributed caching with Redis.

2. Cannot invalidate cache manually
   IResponseCache is internal, which means there is no public API to invalidate cache entries.
   I need to forcefully remove cache entries when an event occurs in my system without waiting for TTL expiration.

3. No reusable CachedResponse API
   CachedResponse has useful functionality for copying HttpContext, but it is not encapsulated in a reusable service.
   If I want to implement custom caching logic, I have to copy existing internal code, which is not ideal.

Describe the solution you'd like

1. Make IResponseCachingKeyProvider and IResponseCache public
   This allows for custom implementations of key providers and caching mechanisms.

2. Extract caching logic from ResponseCachingMiddleware into a separate service
   This makes caching logic more modular and reusable.
   Improves testability and makes it easier to integrate with other storage solutions (e.g., Redis, distributed caching).

3. Optimize the implementation
   If the proposal is accepted, I can submit a PR that includes modern optimizations such as Span usage where applicable.

Additional context

If this approach makes sense, I would be happy to implement the necessary changes and submit a PR.