chore(deps): bump cache2k 1.6.0.Final → 2.6.1.Final

[stian-sandvold]

What

Bump cache2k 1.6.0.Final → 2.6.1.Final (cache2k-api.version), and remove the single 2.x-incompatible API call so the bump compiles.

Supersedes dependabot #23778, which bumped only the version property and therefore failed to compile (all four CI suites red).

The one breaking change

cache2k 2.x removed Cache2kBuilder.resilienceDuration(long, TimeUnit) (the old behaviour moved to UniversalResiliencePolicy in a separate cache2k-addon module). It is used exactly once, in DefaultPreheatCacheService.put().

That method's cache is disabled dead code — DefaultPreheatCacheService.isCacheEnabled() hardcodes return false ("we decided to deactivate the cache in the preheat completely for now"), so the Cache2kBuilder…build() never runs. The resilience setting was protecting a cache that is never built.

So rather than add a new cache2k-addon dependency just to preserve that setting, this PR simply drops the resilienceDuration call. Minimal diff, no new dependency.

Every other cache2k API dhis2 uses is unchanged in 2.6.1.Final — forUnknownTypes, eternal, expireAfterWrite(long, TimeUnit), entryCapacity, name, permitNullValues, build; Cache.get/put/putIfAbsent/remove/removeAll/clear/keys/asMap/invoke; MutableCacheEntry.setValue().setExpiryTime() — and dhis2 imports nothing from the removed org.cache2k.integration package.

Supply-chain notes

• Genuine org.cache2k artifacts (Jens Wilke / cache2k.org), on Maven Central since 2022-02-07, PGP-signed.
• No CVE in either direction (OSV + GitHub Advisory DB clean for 1.6.0.Final and 2.6.1.Final) — not a security-driven bump.
• Transitive footprint shrinks: 2.x drops 1.6.0's non-optional org.jctools:jctools-core runtime dependency; cache2k 2.6.1 is effectively zero-dependency.
• Note: 2.6.1.Final (Feb 2022) is cache2k's latest/terminal release — no 3.x, low ongoing maintenance.

Verification (local, off current master)

• ✅ Compiles: dhis-api, dhis-support-hibernate, dhis-tracker (the three cache2k users) + dependency chain.
• ✅ AnalyticsCacheTest — 6/6 green (exercises a real LocalCache, i.e. the cache2k 2.6.1 get/put/TTL runtime path).
• ✅ AbstractSchemaStrategyCachingTest (tracker) — 2/2 green.

Follow-up (not in this PR)

DefaultPreheatCacheService's cache is entirely disabled and is the only cache2k user in dhis-tracker. A separate cleanup could remove the disabled cache and drop cache2k from the tracker module. (Also: LocalCache/ExtendedCacheBuilder javadocs wrongly say "Caffeine-backed" — the backend is cache2k.)

🤖 Generated with Claude Code

[enricocolasante]

We actually have a task to review caching strategy in tracker. We will have a look then if it makes sense to completely remove it or make it work

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[stian-sandvold]

@enricocolasante Claude was a bit quick on the trigger and automatically tagged you for review before I got a change to research the change.
But after looking through it now, removing this line has no impact, and even if the cache2k code is re-enabled, this line shouldn't have an impact, since we're not using loaders to populate the caches, rather we populate them directly ourselves.

If we do want it back in the future because we want to use loaders, we'd have to include the cache2k-addon dependency as well, which comes with a resilliencePolicy :)

In either case, I think it's fine to merge this, then when the time comes to review the caching in tracker, we can decide whether you need the resillience or not!