The goal is to enable collecting cache traces in production in order to better inform changes to algorithm and / or cache size.

Logs the initialisation, access, and clearing of each category of LRU. As the operation is expected to be expensive the logger is independently set to `INFO` to ensure it does not get enabled when trying to do "normal" debug-logging. This logger should be enabled specifically for that purpose through `--log-handler` at most, ideally it should really be enabled programmatically and its contents should be routed to a separate log file (possibly with a custom formatter, and a higher than default buffer size -- although the default should be an acceptable 8k on 64b platforms).

However this generates information which has to be heavily reformatted (mostly discarding 3 if not 5[^1] of the 7 standard logging fields as useless for our purpose, but also splitting traces during inits and clears), and at the end of the day is a bit of an abuse of logging, this might be better suited to proper tracing integration (or at least structured logging) especially if that has good support for dynamic reconfiguration.

[^1]: database name and pid may be useful / necessary to correctly simulate the sessions as the LRUs are per-worker and most are per-registry