As a partial fix to #496, do not touch the MAC address of the WAN
interface when using VXLANs (as only the MAC address of the VXLAN
interface matters to batman-adv).

This reverts commit 9b1eb40f.

With the batman-adv v2019.2 upgrade reverted (c1a77339), the batman-adv
multicast-to-multi-unicast feature is not available yet. Without that it is
going to be very unlikely of the batman-adv multicast optimizations to
take effect. E.g. some outdated nodes would disable it.

To avoid confusion and diversion with a few communities having it enabled
and most implicitly deactivated, just deactivate it for all for now
until batman-adv is updated to v2019.2 or greater again.

The new routing_algo site.conf value BATMAN_IV_LEGACY is introduced. With
these changes, the routing_algo setting becomes mandatory.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

Several fixes and enhancements related to multicast were added upstream
in batman-adv. So let's give the batman-adv multicast optimizations
another go.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

The commit b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route
to br-client (#1312)") moves the IPv4 prefix from the local-port interface
to br-client. A client requesting an IPv4 connection to the IPv4 anycast
address of the node (the device running gluon) will create following
packets:

1. ARP packet from client to get the MAC of the mac address of the anycast
   IPv4 address
2. ARP reply from node to client with the anycast MAC address for the IPv4
   anycast address
3. IPv4 packet from client which requires reply (for example ICMP echo
   request)
4. ARP request for the client MAC address for its IPv4 address in prefix4
   (done with the mac address of br-client and transmitted over br-client)
5. IPv4 packet from node (transmitted over br-client with br-client MAC
   address) as reply for the client IPv4 packet (for example ICMP echo
   reply)

The step 4 and 5 are problematic here because packets use the node specific
MAC addresses from br-client instead of the anycast MAC address. The client
will receive the ARP packet with the node specific MAC address and change
their own neighbor IP (translation) table. This will for example break the
access to the status page to the connected device or the anycast DNS
forwarder implementation when the client roams to a different node.

This reverts commit b3762fc6 and adds an
upgrade code to remove local_node_route on on existing installations.

net.ipv6.conf.br-client.forwarding is moved from gluon-client-bridge to
gluon-mesh-batman-adv, as the setting is not useful with non-bridged
protocols.

The RFC standard multicast querier interval is 120s. Our querier uses in
interval of 20s for better support of roaming clients, but our robustness
setting of 3 leads to external queriers using the standard interval to be
timeout after only 60s, leading to frequent "querier appeared/disappeared"
messages. Increase robustness so that external queriers with any interval
<180s are supported.

This patch moves the prefix4 subnet route from the local-node veth
device to br-client (while keeping the next node ipv4 address on the
local node device).

This is in preparation to allow routing over the br-client interface
later.

 * gluon-core, gluon-client-bridge: introduce new firewall zone: local_client
 * gluon-core: put clients in local_client zone, introduce drop-zone,
   set dns-rules and zones
 * gluon-respondd: allow respondd on mesh
 * gluon-status-page-api: allow http input on mesh and client

Some files have received some additional refactoring.

When a Gluon node is used to connect to an uplink router/DHCP server (for
example in deployments without VPN tunnels), the gw_mode must be set to
server; this should be preserved on upgrades.

Fixes #1196

[Matthias Schiffer: move to proto_gluon_bat0_setup() and default to BATMAN_IV]

Reverts d5829d87 ("gluon-mesh-batman-adv-core: disable bridge port
learning on bat0").

Fixes #1121

We now create bat0 and primary0 independently of the lower mesh interfaces,
making the whole setup a lot more robust. In particular:

- we can't accidentially destroy primary0 because of concurrent setup and
  teardown runs of different interfaces
- bat0 will always exist, even when no mesh interfaces are up (e.g. no link
  on wired mesh)
- interfaces going down and up again will never tear down the whole of
  batman-adv
- we can enable and disable bat0 independently of the lower interface
  states

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.