feat: support Windows

[nomyfan]

• capture packets from an interface
• conditional compilation
• fix overflow in get_time function

There's one thing needs to pay attention to(in Cargo.toml). Since we only enable pcap's capture-stream feature on unix, we need to update the publish.yml file to pass down the --features arguments for cargo build.

I have not set up the CI for Windows build yet !!!

[jvns]

Thanks so much for your work on this!

4 questions I have:

1. Why does this add an interface flag? Is it because the any interface doesn't exist on Windows?
2. Why does it say to not use the port flag on Windows? (does WinPcap not support using another port?)
3. Do you know why capture-stream doesn't work on Windows? From some very brief Googling it looks like Tokio has some sort of Windows support, but I don't know a lot about this.
4. Does the "" feature work on Windows? More specifically -- if you start dnspeep and then send a packet that doesn't get a DNS response (like with dig @127.0.0.1 example.com), do you see that packet printed out with <no response>?. My guess is that it won't because it's not using pcap's stream feature and so tokio's event loop will be blocked.

[nomyfan]

1. Yes. You can see this example comment from pcap, which points out any is not support on Windows. Moreover, in some scenarios we may only care the packets from the specific interface. With interface flag, we can do this.
2. I think I can do dome adjustments to combine interface with port working together(DONE with 4307ca2).
3. capture-stream feature will enable PacketStream that has the dependency chain PacketStream -> SelectableFd -> RawFd while RawFd aka std::os::unix::io::RawFd isn't enabled on Windows. You can explorer it in stream.rs
4. Yes. It does print out with <no response>, See the figure below.

[nomyfan]

Resolve #15

[sw5ciprl]

abandoned?