pbr: simplify resolver prefill helper to avoid blocking

[pesa1234]

In my situation pbr fail to stop and fail to get service pbr status, when I enable /usr/share/pbr/pbr.user.dnsprefetch.

Openwrt also fail to backup...

After this commit if I enable the script all is back to normal.

• drop ubus listener and named pipes (mkfifo) from the dnsmasq resolver prefill helper to avoid potential deadlocks and blocking behaviour
• wait directly for pbr nft sets (nft list sets inet | grep pbr) with a bounded timeout before doing any lookups
• resolve domains by iterating over $packageDnsmasqFile and calling nslookup 127.0.0.1 in a simple loop
• only run the helper when resolverSetSupported is enabled, the $packageDnsmasqFile exists, and it actually contains at least one domain entry
• keep the helper running in a background subshell so pbr startup is not delayed while dnsmasq/policy domains are being resolved

Thanks

[stangri]

@pesa1234 sorry the current dev branch is 1.2.1. Also tagging @betonmischer86 the author of dns-prefetch script.

[betonmischer86]

Hi @pesa1234! The blocking bug is due to the line
ubus listen -m 'ubus.object.add' > "$pipe_ubus" & ubus_listen_pid=$!
getting the wrong PID on recent OpenWrt builds. Instead, this has been working reliably so far:
( exec ubus listen -m 'ubus.object.add' > "$pipe_ubus" ) & ubus_listen_pid="$!"
I'd prefer to move away from the ubus listen trigger entirely, but I'm not sure the nft set check is a reliable substitute either. In the original ubus listen loop, we're waiting for the specific dnsmasq.dns object to come up. Who knows if it's lagging behind the main dnsmasq for some reason after the nft sets have been populated. Still, you or @stangri may have a better understanding of dnsmasq's inner workings and I could be wrong on this.

As for the nslookup logic forking out seemingly unnecessary background jobs instead of processing packageDnsmasqFile sequentially, the intent was to do the lookups asynchronously in case of a large domain list. Unlike ubus listen, here we have full control over both ends of the pipe to make sure it doesn't block the script.