Fix Pirania issue/1206 and overall captive portal stability

[usg-ishimura]

This PR addresses issue #1206, before this changes when a client connected to a secondary node's AP, the primary node's (wan) nftables received the source mac address of the secondary node itself instead of the client's, blocking in fact internet access for the client even after the authentication process via voucher or read for access. I chose an hybrid solution to the problem checking that ips and macs of the clients are in the authorized lists and adding secondary nodes ips and macs to the whitelists by default. So when a client connects to a secondary node AP the elements in the whitelists should be the mac address of the secondary node and the ip of the client, when a client connects to a primary node AP the elements in the whitelists should be the mac address of the client and the ip of the client. This PR contains the commits from #1219 so i'm closing that one.

This PR can be tested adding this repo in the feeds
src-git libremesh https://github.com/usg-ishimura/lime-packages.git;issue/1206

The update works with my GL-AR300M16 routers on OpenWrt v23.05.5 but it needs further testing for sure.

[ilario]

@luandro @henmohr @tdruiva @bvianna

[henmohr]

Hey, nice work @usg-ishimura!
Just changed gateway.info to thisnode.info (because it's kinda standard for LiMe), copied files to Xunlong Orange Pi R1 Plus LTS running LiMe 2024.1 2024.1 Fantastic Forwarder ((no branch) rev. a9488ae 20250209_1659) , enabled captive portal via lime app, created a voucher and seems to work fine. Need more testing with more devices but it's very proeminent!

[usg-ishimura]

Hi @henmohr,
thanks for testing, the only reason I used gateway.info in the code is because thisnode.info can take the value of both the primary and secondary node, while gateway.info points only to the primary node address, the one that is wan connected. You can see the value that gateway.info take in pirania-mesh-sync