mwan3, mwan4, mini-mwan and further developments

[Jonas Lochmann]

I think that the code from Etienne would be dropped long term. I
dislike the design of keeping "variables" in the file system. Yes, it's
the ramdisk, I know. But after removing that, not much is left from
that ucode development. I see the same issue for mini-mwan - it
communicates using files that contain the current status.

Regarding simple solutions: Before I introduced mwan3, a simple in house
solution based on iperf, a cron job and a simple route replacement was
used. That provided a kind of HA (failover without manual actions), but
no load balancing at all. This looks like mini-mwan, altough it uses
pings instead and does not use cron.

I did not took a closer look at mwan4 yet, but I like the idea. What is
done in it and what is missing? I don't know the possibilities of ucode.
If it does not have good support for parallel processing (ubus,
subprocesses for pings), I actually consider that mwan4 (the C
implementation) a good path forward.

Regarding nftables: I see other options:

- using fw4 as a foundation (thus using its fw4 table); its hook
  mechanism most likely needs to be extended to make this usable
- using the library version of nftables libnftnl (yes, this is still
  nftables, but much nicer than generating text to just throw it into
  a parser as fw4 does it)

I assume that using an own mwan table in nftables would be useful. The
priority system in nftables is flexible enough to make this work
correctly.

I see that we should have talked earlier about this topic.