As core defines basic rules for this zone, it makes sense to create it
there.

 * 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.

In particular, this affects users of gluon.util.iterate_radios.

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

LEDE recently disabled multicast snooping by default:

https://git.lede-project.org/?p=project/netifd.git;a=commitdiff;h=52541140f8138e31958cdc3d7e42a4029fa6bbc9



Reenable it for Gluon as there have been no confirmed issues for
LEDE and no negative reports concerning Gluon v2016.2.x so far.

Closes #1025.

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

gluon-core: gluon.util: pass UCI cursor as argument to iterate_radios() instead of using local context

We always want to prefer the unique node address for outgoing traffic. Note
that this doesn't have an effect with batman-adv, as usually br-client will
be the outgoing interface, so the unique address would be chosen anyways.

macvlan interfaces never directly exchange traffic with the underlying
interface, but only with other hosts behind the interface. In consequence,
router advertisements from the uradvd running on br-client could never
reach local-node, preventing it from getting an IPv6 address without RAs
from an external radvd. Fix this be replacing the macvlan interface with
a veth pair (with the peer interface in br-client).

As a side effect, this saves about 5KB of flash, as the veth module is
simpler than macvlan.

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.

Prepare reverting the roles of br-client and local-node to their state
before 8c4403ba.

Also simplify the local_node.peerdns setting.

We also make use of the boolean support of simple-uci to make scripts
clearer.

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

gluon-client-bridge: add LAN interfaces to client bridge by default (instead of doing this in the batman-adv-specific scripts)

This allows to weaken the gluon-mesh-batman-adv-core dependency of
gluon-luci-portconfig to gluon-client-bridge.

Some drivers (mt76) don't support arbitrary MAC addresses. Use the
addresses provided by the driver (avoiding the primary address) by default,
but fall back to our has-based scheme when the driver doesn't provide
(enough) addresses.