Preferences KDD

[Chris-Petty]

Fixes #5683

[Chris-Petty]

Anything to add, go for it!

Anything I should elaborate on?

I decided for first draft just to get the contextual stuff down and a crack at requirements. Put in the OG prefs option. I haven't gone much deep into implementation details, figured to just agree on requirements and preferred schema/data structure first.

[jmbrunskill]

A thought to add, can we export a group of gloabl and/or default store prefs to apply to a new site/demo?
E.g. if we have a new feature that's relying on a set of prefs, it would be good if we can provide that to support & QA to import for testing or setup.

[jmbrunskill]

Thanks @Chris-Petty I'm suggesting a third option, which is kind of like Option 1 but a bit more limited/focussed. Mostly thinking about how we can use this to create a pref editor UI, think the approach I suggest would work.

More complex stuff wouldn't be done with preferences, or we'd need to extend teh capabilities of the pref options/types.

[jmbrunskill]

Suggested change

	- structs defining pref shape should at least provide some tacit guardrails; if your struct is crazy maybe the pref should be broken down!
	- structs defining pref shape should at least provide some tacit guardrails; if your struct is crazy maybe the pref should be broken down!
	- Requires dedicated code for configuration UI (as we don't know how pref might be structured)

[jmbrunskill]

Suggested change

	- Some preferences might need more than one FK, e.g. user pref for a specific store or machine.
	- Some preferences might need more than one FK, e.g. user pref for a specific store or machine.
	### Option 3 - Similar to `properties` and `name_properties` structure
	With this option we'd define a list of `prefs` in the database that could be assigned, and what possible values they have e.g. float, int, boolean, controlled list.
	Each preference has a `unique_key` assigned, this key is used to assign the value to when serialising/deserialising to json.
	Each pref would record if it's relevent to apply at a global, store, or other level.
	In sync we'd sync a `preference_data` record for each store and one global (for now) could add user, or machine etc as needed in future. This would have a json payload similar to Option 1.
	There's nothing to stop us still deserialise them in a rust struct as needed
	This option would allow us to develop a preference editor UI similar to what we have with editing store/name properties.
	If you need some more complex type in your sync record, then it probably is worth creating a dedicated ui and management for this struct.
	_Pros:_
	- Re-uses an existing pattern
	- Clear path for creating a UI without lots of over head for adding a new pref
	- Can still deserialise to specific structs if needed
	- Could be used by plugins to add additional prefs as needed
	_Cons:_
	- Could be larger payload as prefs aren't broken down into different areas
	- Need to insert prefs into database rather than just adding to code? Maybe there's a code first way to achieve the same thing? Enums?