Integrate juicebox_xml_cache

It'll probably be best to do this in D8 first and then backport.

Here's a draft patch for the local testbots.

Test failures are from changes just committed in #2382533: Attach assets only via the asset library system, which adds a new issue that has to be delt with for this module.

Head changed, so here's an updated patch.

Yeah, so reverse-engineering the way D8 core adds views-based tests turned out to be a bloody nightmare (we need a view to test a case where a gallery display is dependent on the cache). I think I finaaaaaalllly figure it out. Here's a new patch.

Ok, committed. Now back to D7.

Here's a backport for D7.

Hummm, let's try that again.

Well bloddy hell, I simply cannot replicate locally whatever error the testbots are spitting back. It's clearly related to the new test logic and not the changed code. I guess I'll have to figure out some creative way to debug this.

Might have been a stupid oversight regarding the fact that the testbots force non-clean URLs. Trying again...

Alright, so there are working versions of this available for both D7 and D8. However, the more I experiment with this cache logic the more I feel a bit uneasy about it. The concerns that come up include:

• There is no way to safely expire some cache values. Galleries that are dependent on the cache have to store their related XML as CACHE_PERMANENT. This is because we we can't regenerate the XML cache while any other caches (Drupal and external) are holding on to a cache of the gallery's page, and we have no control over the duration of those other caches. This means these entries will sit the bin for a really long time, and anytime a gallery's images or conf is changed the cache will just grow without a constraint.
• Related the point above while we have obsolete cache values in the bin we need to do something special to validate them to ensure that they cannot be used. Without doing this we may be exposing old revisions of entity data to people using old query strings (cache ids) in their XML URL. Without some validation I suppose this could be considered an access bypass. While implementing some kind of validation may be possible, it could be pretty complex to handle correctly.

So I'm just a bit uneasy about things and will probably continue to look into some other ideas.

I'm going to go with a "sub-request" concept to solve this problem, as outline in #2401389: Consider alternate ways to store and generate gallery XML. It should be much cleaner to do it that way. As a result, this can be closed.