Signed-off-by: Sven Eckelmann <sven@narfation.org>

For simplicity, we don't use different MTUs for compat 14 and 15 anymore,
there's no harm in using 1532 for batman-adv-legacy as well.

When preparing the migration from macvlan to veth for local-node, MAC
address conflicts occurred as some ports of br-client had the same address
as local-node. Reverting the roles of both interfaces fixes this.

By default, br-client is left as an interface without addresses and
firewall rules that drop everything, so the bridge is used to connect its
ports only. gluon-mesh-batman-adv-core changes this to the usual set
of addresses and firewall rules.

The batadv debugfs requires large memory blocks to write the text debug
tables. This is inefficient for large tables like the global translation
table or the originators table.

The memory requirement can be reduced by using netlink. It copies smaller
packets in a binary format to the userspace program. The respondd module of
gluon-mesh-batman-adv-core can therefore parse larger originator tables
without causing an OOM on systems which are tight on memory.

Signed-off-by: Sven Eckelmann <sven@narfation.org>

gluon-client-bridge, gluon-mesh-batman-adv-core: switch roles of br-client and local-node interfaces

MAC and IP addresses are switched. This makes the gluon-client-bridge
package more useful for different routing protocols that don't need a
unique address on the client bridge.

As a side effect, gluon-radvd is now using the next-node address, which had
been considered before, but was dismissed to avoid having gluon-radvd
depend on gluon-next-node and gluon-mesh-batman-adv. This will be useful
for announcing default routes via gluon-radvd.

One downside is that this introduces a minor dependency on batman-adv in
gluon-respondd: the hotplug script that checked for the client interface
before will now check for local-node. This doesn't really matter: for mesh
protocols without a local-node interface, the check will do nothing (which
makes sense, as there is no interface to bind to for mesh-wide respondd).

Fixes #941

Most doubles that are delivered via respondd have limited input
precision, but are converted with up to 17 digits of precision. That can
cause ugly blowups like 0.2800000000000001 in the output, which is
avoided by specifying better format strings (like "%.2f" in most cases).

This include wasn't actually missing, but well hidden behind the iwinfo.h
include. Make this more obvious.

Should be redundant after 0bd0df6f

gluon-announced and gluon-announce are merged to gluon-respondd.