perf: Bulk load option set options and restore entity cache [DHIS2-21905]

[netroms]

Summary

GET /api/optionSets with nested options[...] fields executes one optionvalue select per option set in the page (100 sets = 100 selects in the DHIS2-21905 capture), and on a Hibernate query-cache hit additionally re-selects every OptionSet row by id because the entity lost its L2 cache in the OptionSet.hbm.xml to JPA migration (fa6a855).

• Restore the OptionSet entity L2 cache (NONSTRICT_READ_WRITE) with an explicit store-by-reference ehcache region (20k entries, 1h TTL), so query-cache hits resolve entities from L2 instead of PostgreSQL
• Add OptionSetStore.preloadOptions(...): one non-cacheable fetch-join query bulk-loads the options collections absent from the collection cache; warm collections initialize from L2 without SQL
• OptionSetController invokes the preload only when the expanded field paths include options, so requests without options never load them

Resulting SQL shape for a nested-options list request: cold = parent page query + 1 bulk options query, warm = 0 option queries.

Testing

• HibernateQueryCacheTest: a query-cache hit in a fresh persistence context must not reload OptionSet from PostgreSQL (failed with one select per id before the fix)
• HibernateEhcacheConfigFileTest: pins the explicit OptionSet region and its heap bound
• New OptionSetControllerQueryCountTest (Postgres, committed fixtures, real L2): cold nested request uses exactly one optionvalue statement, warm request zero, fields without options load nothing, and committed option scalar updates plus add/remove/reorder are visible on the next request

AI Assisted