Add ffbs-parker-nextnode

[SmithChart]

Thia adds ffbs-parker-nextnode - a package of the parker-flavor of Gluon.

This package provides ebtables-rules that redirect traffic to the
localnode IPs on the node itself.

This is needed in networks where the localnode addresses are outside the client network - for example when
using with parker.

In Freifunk Braunschweig, for example, the localnode address is 2001:bf7:382:0::1.
But the IP addresses of routers and clients are in 2001:bf7:381::.
With this rule traffic to the localnode address is always forwarded to the router.

(The service on the router should redirect the client to one of routers public addresses - otherwise the TCP connection
would break when the client roams to another node with the same redirect.)

Previously this package has been managed in
https://gitli.stratum0.org/ffbs/ffbs-packages under the name gluon-ffbsnext-nextnode.
Last commit-id: 2241cee3e4be96ded955f6bfd40a42cd9b7e53ac

[blocktrron]

@rotanid briefly discussed the compatibility of this package with unpatched gluon - are there plans on upstreaming the necessary core changes to gluon?

[SmithChart]

@rotanid briefly discussed the compatibility of this package with unpatched gluon - are there plans on upstreaming the necessary core changes to gluon?

tl;dr: Yes, we plan to do so.

Long answer: It will take some more steps:

Make sure parker is usable for other communities.
To do so we bring all our packages into community-packages and also start to maintain a fork of gluon that provides a patched base-gluon for others to use.
We at FFBS will keep our gluon modifications away from this in our Gitlab.
We will also need to move our Gluon packages fork with modifications to Github, so others can contribute.

This is where we are at now.

Test the new system, at least in our network (maybe even in other communities)
This way we can make sure that we did not break anything during refactoring.

Fix fallout
Well, I am sure we will break something 😁

Discuss how the patches from our fork can be brought into Gluon
Most of our changes will probably need some compile-time switches in packages built in gluon. This will very likely take some time. And thb I am not sure if I am the right person to handle this.