Configurable dependencies to join an Aggregator

[paul121]

A forward-thinking feature: allow the Aggregator to enforce dependencies on farmOS servers before they can join an Aggregator.

Example dependencies:

• Server version (Require 2x, or later on requiring ^2.3 might be valid use cases)
• Certain modules (a 3rd party module might be required to join an aggregator)
• Resources (log--lab_test might be required on an aggregator)
• Roles (certain roles/scopes must be enabled on the server, likely provided by another module)
• ...

The JSONAPI structure would make it easy to implement some of these features such as checking resources & server version.

[paul121]

Would also need to think what happens when a server becomes out of compliance. The CRON job routinely updates the server info, and could perhaps add ability to notify users/admins when a server is missing a dependency. This might happen when a module is uninstalled.

[mstenta]

Maybe "joining" and "complying" should be separate. I could see an Aggregator being used for multiple purposes, and maybe needing multiple different types of compliances, but maybe not overlap (if that makes sense). This feels very related to the discussions over in https://farmos.discourse.group/t/creating-a-standard-interpretation-layer-on-top-of-core-farmos-schema/533

So perhaps that is more of an application-level decision (higher level than Aggregator), but perhaps Aggregator can provide some helpers? Like "get all farmOS instances that comply with these conventions", or "is this instance compliant?"