User requests an auto-configuration mechanism for "favorites" in client_base, router_late, and router nodes. This is to automatically add neighboring nodes of the same roles as favorites, preventing hops from counting between them. Manual configuration is dynamic and becomes outdated quickly, and remote identification of neighbors is difficult.
### Platform Cross-Platform ### Description With the zero hop policy for "infra-structural" nodes (client_base, router_late, router), we are faced with the challenge of adding the neighbor nodes of the same roles as favorites so that the hops between us and them don't count. We can do it manually when we upgrade, but the dynamic nature of the mesh will make these settings out-of-date. We can do it remotely, but these has some challenges: 1. It's difficult to identify neighbors remotely 2. The feedback from the commands is tricky. We don't know if it works 3. We can't list the current ones So, why don't we automate this? The node can check if the messages arrive directly or not. From the neighbor nodeinfos the node can also check if they have an appropriate role (client base, router late and router). So it could check the favorite option when receiving the nodeinfos. Ideally this should be configurable, from the application. And we could have a way to activate/deactive this option