Well, we don't actually need this. But let's try some patriotism.

At least the ifindex and the flags fields can be larger than 0xff.

Fixes #1523

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.

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)")

(cherry picked from commit 65d172f8)

optional = true does not make sense without a datatype. When no datatype is
set, the empty string will be a valid value, so data is never unset in the
write function. Restore the minlength(1) datatype so the contact setting is
deleted as intended when no value is provided.

The first half was just the package title, the second was outdated.

The field was accidentally removed during the status-page rewrite.

Fixes #1401

gluon-config-mode-contact-info: provide enhancements for german, english and french translation to comply with DSGVO (#1394)

* do not allow to obligatorily require contact information
* add remark that the data is provided voluntarily
* mention how to delete the data
* be very clear about the fact that the data being entered is public and
  can be downloaded and processed by anyone.

This commit adds the ability to show information about the platform on
config-mode reboot.

This commit adds information about:
- how cpu time is spent since boot in jiffies (1/100*sek) (cpu)
    - the value is summed for all cores, so in 10 seconds the
      summed values will increase by 4000, if the cpu has
      4 cores
- context switches since boot (ctxt)
- interrupt counters since boot (intr, softirq)
- forks since boot (processes)

    { "stat": {
       "cpu": {
         "user": 219403,
         "nice": 1714,
         "system": 75159,
         "idle": 2727739,
         "iowait": 2943,
         "irq": 0,
         "softirq": 571
       },
       "intr": 8426340,
       "ctxt": 50992590,
       "processes": 10549,
       "softirq": 5161884
    } }

In multidomain setups, VXLAN is enabled by default, but can be disabled in
domain configs using the mesh/vxlan option. In single domain setups, the
mesh/vxlan option is mandatory.

The UCI option for legacy mode is removed.

Fixes #1364

Fixes: 8e5abf02 ("treewide: switch to ebtables-tiny")

The local_node ifstatus must be checked for local-node, not client. While
we're at it, also clean up the syntax a bit.

batman-adv-specific parts are moved to a new package
gluon-status-page-mesh-batman-adv.

gluon-core, gluon-l3roamd: introduce script gluon-list-mesh-interfaces that lists all currently active mesh interfaces

gluon-status-page: reduce usage of absolute paths in cgi-bin scripts neighbours-nodeinfo and stations

The field is unused.

dnsmasq's caching is severly broken and does not handle all answer records
equally. In particular, its cached answers are missing DNSKEY and DS
records, breaking DNSSEC validation on clients.

Remove the cache for now. It may return if dnsmasq is fixed or we switch to
a different resolver.