Agree & (if applicable) implement approach to storing extension data for entities / tables

We have a fairly common situation whereby extension writers wish to extend a core entity in a minor way. This might involve recording that these 5 contribution pages should be forced to be recurring or this event page should have a specific piece of text inserted by an extension. The status quo is that there is no common method for managing these pieces of data & it's every extension for itself. The wheel is reinvented frequently.

There are to my mind 4 options for how to deal with this

1.  Keep adding module_data fields to tables (either systematically or on-demand)
2.  Move entity setting table / api into core
3. Try to figure out how to ship entity_setting as a default-installed extension (ships with core, maintained as core but sits in an extension)
4. Leave the status quo. Make many special wheels

Module data fields

There is precedent for adding module_data fields to tables - civicrm_menu & civicrm_uf_group are instances where this has been done. We could add module_data field to any and possibly every table in civicrm & provide api handling of that field to unpack the json. There might be some backwards compatibility issues on the api if we start handling the module data field since it is not currently

Entity setting

The entity setting extension is an extension that creates an entity setting table & allows storage of settings on a per entity basis. It requires extension writers to declare their settings in metadata & provides an api to set or retrieve them. Note that it is not intended for high-volume tables as, like the module_data option, it involves unpacking json and I think extensions that have that need should be looking at a different mechanism.

Core extension vs in Core.

This is not changing existing functionality so I don't see it as risky. There might be migration issues for those using the existing entity settings extension but that only affects 3-4 extensions I wrote.  There are 2 benefits to 'actually in core'. 

• The work involved is less & hence it's more likely to actually happen
• If in core it makes sense to edit some templates (e.g manage contribution page) to display entity settings without extension writers having to do that. The existing extension attempts to do that but overall it proved to be too hard / unreliable in an extension without quite a lot of additional effort

There are no specific disadvantages to in-core - it's primarily philosophical.

Civix

If we go for one of the 3 'solution' proposals then it would entail adding a function to civix that checks for the existence of module_data or entity_settings & extensions that leveraged the functionality would be expected to either degrade gracefully (reduce functionality) if not present or to have their own way of messaging to the user that there is an action they need to take to make it work