DPI Http01 solver for linux with nfqueue

[orangepizza]

This pull request will add http.nfqueueport option, which when assigned a port will put a nfqueue rule on firewall to capture http request for token path, block it to reach web server and craft request packet for it. (Linux only)
Why anyone do that? because with this solver it don't need to care about any webserver on port 80.

Why this is draft PR? because this is just enough to run, and much to do yet (ex: currently can't handle ipv6 (not sure it skips or panics), no reasonable docstring, and some more bugs maybe)

using nfqueue for port-sniffing solver isn't my original idea:
https://community.letsencrypt.org/t/using-nfqueue-on-linux-as-a-novel-webserver-agnostic-http-authenticator/192625/23

http.nfqueueport is with port number option so run on pebble, but does it really need to set a port number or just blindly running on port 80 is enough?

[ldez]

Hello,

do you know that every commit creates a notification even with draft PR?

Can you try to reduce the number of commits? Thank you.

Otherwise, maybe you can clean a bit your current commits.

[orangepizza]

this creates about 10 lingering empty packets sent by webserver to acme server, but as server

it was not that bright idea to edit on window and push it to linux vps with git push-pull. well squash everything until now

[ldez]

you have a problem with your rebase 😉

[orangepizza]

rebase done I don't have ipv6 server, so I have no idea what will happen this got ipv6 packet.
iptable rule doesn't look like it will catch v6 packet but who knows?

[orangepizza]

@ldez Kinda want to have testing for this, but as this is requires root to do anything (as this requires to set nfqueue)
and run entire test as root doesn't sound like a good idea

[orangepizza]

nfqueue_linux_test.go needs root (sudo in it won't cut it) so can't run in CI