Add a shared cache

Drupal 7 added the new cache_bootstrap bin, and system_list() that tries to use one cache object to store multiple items that are needed together. However this isn't consistently used, and there are still a very large number of individual cache_get() calls during D7 page requests (albeit replacing individual database queries in D7), often for things that are always needed together.

#1011614: Theme registry can grow too large for MySQL max_allowed_packet and memcache default slab size adds a new CacheArrayObject, which allows a large global cache to lazy load parts of itself when requested - when the potential number of items in the cache is often a lot higher than the number of items that are actually requested during normal operation (schema definitions for tables that never have drupal_get_schema() called on them for example).

The trade-off with that approach, at least when it's fully applied is this:

- current D7/8 - rebuild one very large cache item as soon as it's requested. Load that into memory on every/most requests. This has the advantages of one cache write, but disadvantages of high cost to build for the request that hits a cold start and high memory usage on every page.

- CacheArrayObject - build the cache object over time as keys are requested (hopefully without an initial full load although not all current patches can skip that step). This requires additional cache_set() (although a maximum of one extra per page that gets a cache miss, not one for each key), but the memory usage should be dramatically reduced. It should also allow the cost of cache misses to be spread out over multiple requests (i.e. we may be able to get away with not loading the full theme registry in one go ever eventually unless specifically requested, although that's a way off).

So IMO this pattern makes a lot of sense - it is a compromise between loading a single huge object or array into memory - which leads to very high overall memory requirements (and a lot of data being moved around), compared to always lazy loading individual pieces, which leads to lots of little pieces of data being moved around - separate i/o requests to the database or cache backend.

If that pattern can be applied to individual systems, it still leaves us with the issue of having a lot of different, hopefully relatively decoupled systems that need to load stuff on every request to Drupal - this can be a mixture of configuration and other stuff (i.e. the theme registry is not config, nor is a lot of what gets put in the variables system).

So, if the individual items can be kept as small as possible, I think it is worth looking at introducing a shared cache object for these. This would function something like the CacheArrayObject patch (not necessarily that API although it might work).

Let's call that SharedCache.

__construct() loads the shared cache item from the cache backend.

When a key is requested, if it's cached, it's pulled straight from memory - no separate round trip (what system_list() does now but not a hacky one-off).

If the key is missing, it is either pulled from an individual cache item, or triggers a cache miss. This will generate the content, and it'll be set to write through back to the shared cache.

This means that the shared cache object never really gets cleared, each system maintains their own cache as they do now, but the API piggybacks them onto one item internally.

Potentially this could automatically key based on request - so GET/POST and html vs. other content types. That'd mean you could use the shared item transparently, but internally it would maintain separate items based on request context, which would avoid it getting polluted with too much irrelevant stuff.

I don't have anything written yet, I'd probably want to get some of the memory patches sorted out before even looking at this, but writing it down while I think of it.