Supervisor: RFC: Add-on configs

[pvizeli]

Context

Every Add-on have a differen aproach to solve the issue if people need to be able to edit files. All the approach have the same issue, that the data are not part of the snapshot/restore/cleanup. It make also that is part feel as foreign body.

Decision

We add a new config helper they can be requested by Add-on. /config will be show internal inside Add-on and for the user they will have a new /config/**add-on** folder structure for edit files. /data stay internal while /config can be access from outside. The old /config will be expose as /core and need mapped with core flag if you want have all add-on config, the flag is data.

For the first 2 month, we make an fallback to avoid breaking or missing folders for a soft migration.

[balloob]

Is /config shared between Home Assistant and add-ons?

[frenck]

I think we should avoid renaming the current /config to /core. While it makes more sense, it does impact all documentation and can be breaking for automations or things people do with hardcoded paths (e.g. running shell command, using ssh keypair and whatever else they think of).

As a counter-proposal, the /addons folder has been misunderstood in general quite a bit. I often have had question about that folder (e.g, "What is it for?", "I've installed this add-on and nothing shows up there"). So, maybe use /addons/**add-on** as the public data configuration folder instead and move the local (custom) add-ons folder to /custom_addons (which matches the expectations with the custom integrations method).

[balloob]

Let's avoid making breaking changes. We can add an /addons_config ?

[frenck]

The repurposing of /addon should not be a breaking one.