Fixes #1659

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 is extremely problematic here. ARP replies with the anycast IPv4
address must not be submitted or received via bat0 - expecially not when it
contains an node specific MAC address as source. When it is still done then
the wrong MAC address is stored in the batadv DAT cache and ARP packet is
maybe even forwarded to clients. This latter is especially true for ARP
requests which are broadcast and will be flooded to the complete mesh.

Clients will see these ARP packets and change their own neighbor IP
(translation) table. They will then try to submit the packets for IPv4
anycast addresses to the complete wrong device in the mesh. This will for
example break the access to the status page to the connected device or the
anycast DNS forwarder implementation. Especially the latter causes extreme
latency when clients try to connect to server using a domain name or even
breaks the connection setup process completely. Both are caused by the
unanswered DNS requests which at first glance look like packet loss.

An node must therefore take care of:

* not transmitting ARP packets related to the anycast IPv4 address over
  bat0
* drop ARP packets related to the anycast IPv4 when they are received on
  bat0 from a still broken node
* don't accept ARP packets related to the anycast IPv4 replies on local
  node when it comes from bat0

Fixes: b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route to br-client (#1312)")

Filtering by MAC address won't filter out multicast packages like router
solicitations, causing uradvd to send out router advertisements with
maximum frequency (every 3 seconds) in active meshes, even when no local
client is actually interested in the advertisements.

Fixes #1230

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

The next-node MAC address doesn't need to be unique in different
communities, so we can as well add a default value.

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.

Also move it to gluon-mesh-batman-adv, as mesh_on_wan is the only feature that
needs a unique MAC address on the WAN interface.

The now empty gluon-firewall is removed.

This will make a node announce all MACs of its interfaces participating
in the batman-adv mesh. This enables other nodes to associate the
announced object with both the data reported by batadv-vis as well as a
simple list of neighbours as output by `iw dev $IFACE station dump`.

All announce.d scripts have been moved to /lib/gluon/announce/announce.d
The script /lib/gluon/announce/announce.lua will collect all information
and output json.

This also fixes the type of a few fields which were strings instead of numbers.

For security reasons we should not accept incoming packets per default
and instead allow specific services on specific interfaces.

gluon-mesh-batman-adv should not be used without firewall to prevent forwarding
of packets from the mesh to the wan interface.

For some reason, the firewall package won't work at all without
kmod-ipt-nathelper.

Disabling forwarding prevents the node from reacting to the Subnet-Router
anycast address.