Cache strategy review: contentconstraint + values

[aborruso]

After issue #24 (ISTAT on contentconstraint), the new typical flow on ISTAT is:

1. opensdmx constraints <df> --provider istat → fetches contentconstraint (sub-second) and tells the user some dims are missing
2. opensdmx values <df> <DIM> --provider istat → fetches the codelist for the missing dim

Both are already cached:

• available_constraints SQLite table → 7-day TTL (CONSTRAINTS_CACHE_TTL, 604_800 s)
• codelist_values SQLite table → 30-day TTL (METADATA_CACHE_TTL, 2_592_000 s)

What this issue tracks: a deliberate review of the cache strategy now that contentconstraint + values is the canonical "get the codes I need" pair.

Questions

• Are TTLs appropriate? contentconstraint payloads change rarely; codelists change even less. 7 days vs 30 days feels arbitrary.
• Should the two be co-stored / co-invalidated? Today an explorer command fetches them separately, possibly with one cached and one expired.
• Is there value in pre-fetching codelists for missing dims when constraints is called? (Tradeoff: extra HTTP round-trips per command vs. faster follow-up values.)
• Cache size monitoring: do we surface cache hits / sizes anywhere? (opensdmx providers?)

Background: requested while implementing issue #24 (suggestion from @aborruso during the planning conversation).