Document how IPv4 routing works in gluon

This issue tries to untangle the mechanisms that exist in Gluon to make a reliable setup easier.

[Gluon Config Docs](https://gluon.readthedocs.io/en/latest/user/site.html#configuration)

### local node support (aka anycast)

This feature allows client to reach the node they are connected to using a stable layer 2 (mac) and layer 3 (IP) address. Gluon uses ebtables rules and ARP to realize this.

Example:

```lua
next_node = {
ip4 = '10.23.42.1',
ip6 = 'fdca:ffee:babe:1::1',
mac = '16:41:95:40:f7:dc',
-- DNS names to be statically configured for reaching the anycast IP (optional)
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
}
```

### batman gateway selection (aka DHCP filtering)

[batman docs](https://www.open-mesh.org/projects/batman-adv/wiki/Gateways#Routing-towards-the-best-internet-uplink)

the gateway feature of batman allows to ensure that DHCP requests will only be forwarded to a single DHCP server even if multiple exist on the mesh.

This means that it's possible to run a DHCP server on each gateway without the need to synchronize their state or do leader election to decide which is the designated server to reply to requests.

## consequences for the supernode setup

- all supernodes can run their own DHCP server
- DHCP servers don't need to do leader election
- DHCP servers don't need to sync their state if their pools are disjoint sets
- no VRRP needed, the anycast IP can be announced in DHCP

Open questions:
- If the anycast address is used in DHCP, what default route do the gluon nodes use?