Handle automatic cache purge (avoid capacity overflow)

[chillu]

Overview

Followup to #6252: We're using a new cache library, and still defaulting system caches to Filesystem (although we're choosing APC/opcache if available). As opposed to the old Zend_Cache solution, there's no way to limit the size of the cache. This leads to potential server capcity issues when old cache keys accumulate, particularly if they're based on timestamps as part of the cache key. The server might run out of disk space, or exhaust its filesystem nodes.

This issue should be solved in symfony/cache itself, so I've filed it there: symfony/symfony#21764 (comment)

Depending on the outcome, we might need to do more work in the framework to ensure a new purge() API is used automatically.

Acceptance Criteria

• Expired cache entries get purged
• This is enforced automatically (in-process cache purge for expired entries)
• In-process cache purges don't exhaust server resources (PHP exec or mem)
• Devs can opt in to background cache purging via a cron task
• Continues to support non-expiring cache entries (acknowledging that they might get garbage collected when file size limit is reached)
• Continues to support caches which aren't filesystem based (and do their own garbage collection)
• Cache behaviour is well documented

Notes

• Talk to platform operations about impact to their hosting context

[lozcalver]

@chillu That functionality has been added now (3.4+), I’m guessing this still needs to be addressed?

[chillu]

@kinglozzer Looking at the commit, it seems that there's a manual prune task - which we'd need to advise SilverStripe devs to set up as a cron job. Until we both upgrade to Symfony 3.4 and add those docs, I'd keep this issue open.

[chillu]

Documented here: https://symfony.com/doc/3.4/components/cache/cache_pools.html#pruning-cache-items

I think we can't really rely on cron jobs, and should do it the Zend way of randomly calling this prune command when caches are accessed. This will lead to some instability in request times, but it's no better or worse than in 3.x - where people largely didn't even notice this was happening. Note that not all cache interfaces support automatic pruning, so we'll need to add that to our documentation on how caching works. And recommend for people to disable this behaviour in favour of a cron job.

[chillu]

Raising up in backlog because there's no easy workaround, other than completely wiping cache (incl. non-expired items), which can lead to cache stampedes