Relay configuration interface

[adriansmares]

Summary

References #6728

Changes

• Decouple relay parameters (i.e. what is inside the MAC state current/desired parameters) from relay settings (i.e. what sits inside the MAC settings) in the API.
  • This makes concepts such as MAC profiles and defaults easier to execute upon - the parameters are always fully instantiated, while MAC settings can still be partial to a small extent. It also serves as a very trivial space saving measure when defaults are used.
• Add the relay configuration service. It allows both configuring the relay (to serve other devices, or to be served by a relay), and configuring the uplink forwarding rules (i.e. which devices are attached to the relay).
  • It allows basic CRUD operations for the relay configuration of an end device.
  • It does automagic functionality for the caller, such as automatically retrieving the session key ID for the served end devices, retroactively affecting existing sessions and pending sessions.
  • Updates are guaranteed to be atomic by the server, which is not achievable for the uplink forwarding rules otherwise.
  • The validation follows the proposed format from Refactor Network Server end device registry Set method validation #6732 , as a preview of how this would work in practice.
  • The CRUD is actually separating Create from Update, as opposed to our usual Set methods, in order to create semantic clarity.

Testing

Local testing with Postman. A subsequent PR will add the associated CLI for this new service, along with extra unit testing.

No manual testing will be required for this PR - the CLI will be the good way to test this manually.

Regressions

The new settings message is binary compatible with the old parameter message, although two fields (the backoff and the default channel index) have had their format change (from uint32 to UInt32Value) - this is fine as this API and functionality were never released officially nor are the two fields extremely important for already registered relay-enabled devices.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• The steps/process to test this feature are clearly explained including testing for regressions.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[johanstokking]

LGTM but can we expand the scope of #6728 at least to include a client, i.e. CLI? And file an issue for Console support?