DB logging is not optimal with fix for CRM-12337

From CRM-12337, the menu is cached as compiled JS and a generated random key stored in the settings table, with an entry for each contact ID.

If DB logging is enabled, this can lead to the table log_civicrm_setting growing rapidly with each reset of the site's navigation.

On some sites I've observed this leading to crashed ARCHIVE tables etc. With a few tens of thousands of contacts (and possibly some other code triggering navigation rebuilds?) this can result in millions of entries in log_civicrm_setting.

It feels like this approach might be using civicrm_setting as a cache, rather than as a settings table? Looking at civicrm_settings table on an affected site, there are ~500 entries which are NOT name='navigation', and 17K which are name='navigation'. That smells wrong to me, do we expect civicrm_setting to have entries per-user?

(In the time it took me to write this ticket, the affected site updated the value of all those items, and created a single item which is serialized but looks very similar.)

select count(*), value from civicrm_setting where name='navigation' and contact_id is not null group by value;
+----------+-----------------+
| count(*) | value           |
+----------+-----------------+
|    17000 | hOiJsQgo        |
|        1 | s:8:"ZJPX5flL"; |
+----------+-----------------+
2 rows in set (0.17 sec)