respondd structural roadmap

[christf]

We currently support multiple mesh/routing protocols that each have their respondd module.
Each module implements statistics including nic traffic, information about neighbours and routing.
Some technologies are fundamentally different between mesh protocol implementations, however others are the same:

• iterating over mesh interfaces (use UCI)
• iterating over all interfaces (use UCI)
• obtaining NIC traffic statistics
• obtaining IP addresses
• obtaining routes
• the gateway_nexthop field should be adjusted to match rename gateway_nexthop fields in statistics FreifunkBremen/yanic#170 un-batman-i-fying this part of the response structure.
• Large respondd.c implementations should be broken down into statistics, nodeinfo and neighbour files as done in gluon-mesh-* respondd cleanup (part 1?) #1879 for the batman module.

[genofire]

is there any update on this, or could we close the yanic issue?