Fix memory leak in CaffeineCacheManager static mode

[NYgomets]

Description

This PR fixes a memory leak in CaffeineCacheManager where dynamically created caches were not removed when switching to static mode via setCacheNames().

Changes

Core Fix

• Modified CaffeineCacheManager.setCacheNames() to clear dynamically created caches while preserving custom caches
• Updated Javadoc to clarify the behavior

Tests Added

• setCacheNamesShouldRemovePreviousDynamicCaches(): Verifies dynamic caches are cleared
• setCacheNamesShouldPreserveCustomCaches(): Ensures custom caches are not affected
• switchingBetweenDynamicAndStaticMode(): Tests mode transitions

Backward Compatibility

This is a potentially breaking change for users who rely on the (undocumented) behavior of dynamic caches persisting after setCacheNames().

However:

1. The current behavior violates the documented contract
2. The memory leak justifies the fix
3. The typical use case (setting static caches at startup) is unaffected

[jhoeller]

On review, setCacheNames is really a configuration-time method and not meant to be called at runtime when caches already exist. That said, point taken that it can effectively be used for re-configuration purposes as well, so we need to take that into account to some degree.

For the specific case of "leaking" dynamic cache regions when a new set of fixed cache names is being configured, these formerly registered dynamic regions keep being accessible, so they are not really leaking. Also, if a specific set of cache names is set through setCacheNames initially, and then later on a smaller or different set of cache names is set on yet another setCacheNames call, we are not removing the old caches either, rather just adding the newly specified ones. The registerCustomCache facility makes the semantics even less clear there since those are always worth retaining.

Overall, I don't see us adding official clean-up semantics to setCacheNames. Instead, we're introducing a resetCaches() method (#35840) which can be called before setCacheNames if such clean-up is desirable: That method can generally be used for cache clearing at runtime, removing dynamic caches or simply clearing static caches. This goes nicely with the existing removeCache method that we introduced in 6.1.15 (#33813).

Thanks for the PR, in any case!

[NYgomets]

Thanks for the detailed explanation, Juergen.

I understand the design philosophy regarding setCacheNames as a configuration-time method and the risk of implicit cleanup. Introducing an explicit resetCaches() method seems like a much safer and more flexible approach to handle runtime reconfiguration scenarios.

I'm glad that my report contributed to improving the cache management capabilities. Thanks for addressing this!