Simplify caching of status checks

[colemanw]

Overview

Simplifies code and improves performance during system status checks.

Before

• 'domain_id' was missing from the api params, which would have caused unexpected results and possibly crashes in multi-site setups.
• Civi::cache was being read but never written to.
• Non-static object caching did not persist in memory across different check classes and since there was no data in Civi::cache this caused multiple redundant queries (one per CRM_Utils_Check_Component_* class).
• If we did write to Civi::cache there is no mechanism for clearing that cache when data changes.

After

Solution: use simple array cache a-la Civi::$statics

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

Ping @eileenmcnaughton

[eileenmcnaughton]

@colemanw I can see it was broken but I don't think I get why we ditched civi::cache:

"If we did write to Civi::cache there is no mechanism for clearing that cache when data changes."

Isn't the point that it is cached for a period of time & then it ages out? This doesn't seem more change prone than 'anything else'

[eileenmcnaughton]

I think testing caching is crazy difficult and at this level it doesn't make sense

[colemanw]

I'm not sure I can be said to be ditching it here as it wasn't actually getting used in the first place.

We pretty much use CIvi::$statics for everything so I'm not sure what makes this particular case special that it needs extra caching?

[eileenmcnaughton]

@colemanw since the cache system got improved we've been using it more - using a 'fastArray' cache means a static cache sits in front of 'the other' cache - so for Redis there is no DB query at all & once retrieved you still get the benefits of array caching. Generally I have been using civi::cache('metadata') for all not-constantly-changing stuff - contact types, membership types, price sets etc

[colemanw]

I'd be worried about time-based caching causing bugs here, as these settings can be changed & then the cached data would be wrong. IMO if we're going to use a cache we'd also need to clear it in the StatusPref BAO for every write operation.

[colemanw]

@eileenmcnaughton looking at this again, I found an actual bug: domain_id' was missing from the api params, which would have caused unexpected results and possibly crashes in multi-site setups.

So now that this PR fixes a real bug and simplifies things in general, can we go ahead and merge this first and then take a look at the caching issue second

[colemanw]

Test fail is unrelated

[demeritcowboy]

@colemanw - File conflicts

[eileenmcnaughton]

OK - I'm not convinced about reducing our caching - but this should be a cheap call