Statelessness: Settle on a uapi / freedesktop "hermetic /usr" compatible statelessness story

[ermo]

Historical context

For context, Ikey has been in the stateless game at least since the days when he worked on Clear Linux at intel's OSTC.

This definition of stateless, via Ikey, made its way into Solus, where the de facto standard was to have per-package stateless configuration saved to /usr/share/defaults/<packagename>.

Current state of statelessness

Per the uapi-group configuration files specification and the freedesktop file-hierarchy specification, we may want to consider building a "hermetic /usr" story which is as compatible as we can make it with Ikey's preferred Clear Linux-derived statelessness approach.

Goals and non-goals

The longer term goal is to avoid getting into a situation where our definition of statelessness clashes with the upstream "hermetic /usr" approach, to the point where upstreams refuse to accept patches related to our definition of statelessness, thus forcing us to maintain an unbounded number of downstream patches that have no upstream relevance.

Instead, we may want to make it so that we have a well understood and agreed upon way to integrate upstream "hermetic /usr" compatible packages in our recipes, to the point where we can reliably get statelessness patches accepted upstream, whilst seamlessly benefiting from them in our package recipe maintenance story as a downstream distribution.

Concrete implementation suggestion

One option we have is to keep our current %(vendordir) macro (resolves to /usr/share/defaults) and then also add a %(factorydir) macro, that resolves to e.g. /usr/share/factory/etc (TBD!), for the case where it makes more sense to use a shared, (...)/etc/foo.d/ configuration drop-in layout?

Another option is to consolidate completely and use %(vendordir) = /usr/share/defaults/etc/, which would essentially displace the need for a separate %factorydir macro. Up until a certain point, I think this was actually our previous boulder default.

@ikeycode thoughts?

Context: AerynOS/recipes#597 and #419