File cached Metadata Exposed Endpoint (but a different cached behavior)

[DiegoPino]

What?

Most of you might have Twig templates that render in real time and for that the current Drupal based JSON Cached response is actually good enough. But there are a few cases when we need to act differently, specially for Metadata Outputs (JSON or XML) that are of multiple Megabytes and might even take a minute (or two) to build if called over and over in realtime.

The idea here is to enable/allow an extra option that provides a Cache-warmer for endpoints that have this enabled (just a help to speed things up) and a File based Cache (static file generated) that will be served not only "until something changed" and then try to rebuild in realtime (while the user waits for ever- like cache-tag expiration) but actually keep serving an "oldie" until a replacement/via backed/async or shutdown function call was produced. I might even throw a lock here in case multiple concurrent users are calling the same cache-regeneration (basically just hitting an endpoint that needs refreshing)

PHP has actually a method to keep running a method AFTER the response was sent. This one here is actually opinionated but matches Archipelago's very specific deployment (we are already using PHP-FPM) and we could tie this to the

https://www.php.net/manual/en/function.fastcgi-finish-request.php

Another option (maybe a config) would be to simply enqueue the need. And even this fact could be dynamically, we could measure time to produce for a single ADO a cache, if exceeds X time, from there on automatic File caching comes in place.

@alliomeria this is useful for:
39MB (or 40MB) XMLS from EADs
Real, rich, complex IIIF Manifests with hundreds of canvases.