The localization translations REST resource sets no cache headers

Context

TranslationsResource, in xwiki-platform-localization-rest-api, serves the translations consumed by the front-end localization resolver and by the xwiki-l10n RequireJS loader plugin. It is a plain @GET with no cache directive.

Actual

The resource sets no Cache-Control, Expires, ETag or Last-Modified header, so every front-end component that needs translations re-fetches them on every page view, even though it asks for the same keys in the same locale each time.

Expected

The response carries cache headers, so that a browser can reuse the translations it already holds instead of fetching them again on the next page view.

The result depends only on the wiki, the locale of the request context and the requested keys, all three of which are part of the request. It changes only when a translation bundle changes.

Suggested fix

Derive an ETag (or a Last-Modified) from the version of the translation bundles the answer was built from, and honour the conditional request, so that a repeat call costs a 304 instead of the full payload.

Mind the invalidation constraint when choosing between that and a plain max-age: an administrator who edits a Translations document expects the new values to show up, so a long max-age would keep serving stale translations, whereas a cheap revalidation would not.

Related: XWIKI-25008, which reduces the number of these requests; this issue makes each remaining one cheap on a repeat visit.