(dev/core#174) systemStatusCheckResult - Migrate from settings to cache

[totten]

Overview

This is fundamentally an ephemeral value, and it's apt to being recalculated at arbitrary times. Storing this in the settings table limits the efficacy of read-only database.

See also: https://lab.civicrm.org/dev/core/issues/174

Before

• The footer of every admin page shows a pre-computed general status. This pre-computed value is periodically updated. The value is stored and read using Civi::settings().

After

• Same as before, but hte value is stored and read using Civi::cache('checks').

Technical Details

• The checks cache may be stored in memory-based service, or in a civicrm_cache SQL group, or in a static array. (It uses the best-available storage.)
• You may concerned about how the lifecycle of this cache compares to the old settings-based lifecycle. In the settings-based lifecycle, the value is separate and immune from normal cache-flushing. Do we get the same immunity when it's a cache? Yes and no. (For simplicity, I'm going to assume a related PR (dev/core#174) CRM_Utils_Cache - Always use a prefix. Standardize delimiter #12331 is merged.)
  • If you have a memory-backed cache, then it's separate by virtue of using different prefixes.
  • If you have a SQL-backed cache, then it can be cleared... but only when one of the following is triggered:
    • General system flush (System.flush aka cv flush aka rebuildMenuAndCaches -- which is done manually or as part of a system-lifecycle task, like installing new extensions)
    • CRM_Core_Config::cleanupCaches() (which can be triggered by the above -- or by major DB upgrade)
    • CRM_Core_Config::clearDBCache() (which can be triggered by the above -- or by Job.cleanup dbCache=1, CRM/Utils/Migrate/Import*, or the GUI page "Settings - Cleanup Caches and Update Paths", or any page based on CRM_Admin_Form_Setting)

Most of those seem like reasonable (and infrequent) occasions to clear it. I suppose CRM_Admin_Form_Setting is more debatable:

• Usually, after editing a setting, the status-check results don't change. During the early days of setting up a new system, you may edit settings frequently.
• Sometimes, after editing a setting, the status-check results do change.

If the last one is worth arguing over, then I assume someone will argue over it. ;)

[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).

[seamuslee001]

@totten any reason why we are needing the 2 elements rather than just an array like ['js_strings','community_messages','checks']

[totten]

This is a cherry-pick from #11896, which has a few more draft patches which update the same array. Some of those use-cases could work with ['js_strings','community_messages','checks'], and one wouldn't. It's easier to juggle the patches (rebasing, re-ordering, cherry-picking, avoiding conflicts, etc) if they all use the use the same multi-line notation.

[eileenmcnaughton]

I took a look at this & it makes a lot of sense - merging