This removes PKG_VERSION and PKG_RELEASE from most Makefiles, as the
value was never useful for Gluon packages; instead, PKG_VERSION is set
to 1 in gluon.mk.

It also removes two other weird definitions:

- gluon-iptables-clamp-mss-to-pmtu replicating the old PKG_VERSION logic
  from gluon-core, but without the fixed PKG_BUILD_DIR to prevent
  unnessary rebuilds
- gluon-hoodselector set GLUON_VERSION=3

[Matthias Schiffer: fix up start/stop order and file permissions]

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.

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

Avoid commiting configs inbetween to decrease number of flash writes.

Fixes #714.

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

By not executing all scripts from gluon.announce themselves, both should
be considerably faster and lighter on RAM usage.

This adds a new announce.d datum "neighbours" (alfred 160) containing
information about mesh neighbours. It's intended to be an replacement
for batadv-vis.

In addition to the data already provided by batadv-vis it'll also
provide information about direct wifi neighbours.

Unlike batadv-vis, no data about clients is transmitted.

Sample data:

    {
      "wifi": {
        "90:f6:52:82:06:02": {
          "neighbours": {
            "f8:d1:11:2c:a7:d2": {
              "noise": -95,
              "inactive": 0,
              "signal": 0
            },
            "96:f6:52:ff:cd:6f": {
              "noise": -95,
              "inactive": 0,
              "signal": -37
            }
          }
        }
      },
      "batadv": {
        "90:f6:52:82:06:02": {
          "neighbours": {
            "96:f6:52:ff:cd:6f": {
              "lastseen": 2.8500000000000001,
              "tq": 177
            }
          }
        },
        "90:f6:52:82:06:03": {
          "neighbours": {
            "f8:d1:11:2c:a7:d3": {
              "lastseen": 2.3500000000000001,
              "tq": 206
            }
          }
        }
      },
      "node_id": "90f652820602"
    }

Moving the scripts to a common directory not only vastly simplifies the
zzz-gluon-upgrade script, but also allows to define an ordering of such
scripts across packages.

Signed-off-by: flokli <florian@darmstadt.freifunk.net>

This should reduce memory consumption a little.

https://github.com/freifunk-gluon/gluon/issues/109#issuecomment-61681696

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.

This replaces announce.sh with a lua script of (hopefully) equal
functionality. Using lua generating JSON is much faster than jshn and
allows for greater flexibility.

The run frequency and exact time affect the alfred announce interval, so we can
just run it every minute to supply alfred with the most up-to-date data.

+ mgmt and forward counters
+ packet in addition to byte counters for everything

After a lenghty discussion, we settled on absolute vs. relative values.
Main reasons:

* stateless implementation on node possible
* convertable to relative values by differentiaion on receiver
* missed transmissions only decrease granularity, whereas relative
  values would introduce wrong numbers on integration if values are
  missed