Support UAPI-style configuration specification

[doganulus]

Linux User API Working Group has a Configuration Files Specification for modern applications. This specification establishes where configuration files should be looked for, in which order, and how precedence, masking, extensions, and overrides work. It is implemented for systemd, the flagship example of this configuration style.

This discussion is about how this configuration style can be applied to the Zenoh project. It definitely would bring many benefits to handling configuration complexity across the ecosystem, yet some deviations from the specification seem necessary.

Pros:

• Robotics community already moves to hierarchical configurations yet ad-hocly. See the thread on the ROS forum.
• Other Eclipse projects like Bluechi also uses a similar configuration hierarchy inspired from systemd.
• Modern software engineers increasingly prefer this style; therefore, it has momentum.

Deviations from the specification:

• The existing and recommended implementation libeconf for the specification is written in C and supports an INI-like format. Zenoh and the robotics community use more complex configuration formats like JSON and YAML. Therefore, applying the concept to these formats would require an additional implementation effort.
• Multiple file formats (extensions) are not considered in the specification. Therefore, a precedence relation must be defined among file extensions such as yml > yaml > json > json5. This is non-standard, as far as I know.
• Zenoh plugins and applications would probably need heavy configuration; therefore, the router's configuration is not the only concern here. Yet the drop-in concept can especially be helpful for configuration fragments, as asked here. But, of course, this requires more design work.

However, let's look at how it may look once implemented. Assume a configuration hierarchy is defined for Zenoh as follows (lowest precedence is first):

• /usr/local/zenoh/config/
• /run/zenoh/
• /etc/zenoh/
• $HOME/.config/zenoh/

Example 1:

• /usr/local/zenoh/config/zenoh.json (default router configuration is here)
• /etc/zenoh/zenoh.d/01-plugin-rest.json (this merges with the default)
• /etc/zenoh/zenoh.d/02-namespace-my_app.yml (this merges with the previous and uses the exact mechanism to configure my custom app via the object at the key apps.namespace.my_app)

Example 2:

• /etc/zenoh/zenoh.json (masking /usr/local/zenoh/share/zenoh.json)
• $HOME/.config/zenoh.d/my_local_override.yml (users add or overrides)