Add do_io on peek for TcpStream

[Sytten]

Fixes #1755
I am not sure of the implications of this change for all platforms, but it fixes the issue on windows. I believe it should be fine on unix too, but more tests are needed.

[Thomasdezeeuw]

This is incorrect. Peeking shouldn't reset our readiness internally as more data can be read (when not peeking).

[Thomasdezeeuw]

FYI its a potential security issue that cirrus ci runs without any approval, probably should restrict that...

We have no secrets, so it's not really.

[Sytten]

This is incorrect. Peeking shouldn't reset our readiness internally as more data can be read (when not peeking).

I am not sure I understand what that means. A peek does currently reset internal readiness if it would would block which is fine since we need to wait for more data to come in. A read also reset internal readiness. If you don't reregister the interest with the OS when that happens (which is essentially what do_io does) then I am not sure how we expect this to work at all. I am a bit surprised that Unix currently work, seems more like an accident than planned behaviour to me but I didnt check the code much.

[Thomasdezeeuw]

If a peek call returns a short read (peek) on Unix it will trigger our internal registering mechanism, but it shouldn't.

[Sytten]

Does internal mean the readiness stored in ScheduledIO or the libc/iocp calls?
EDIT: This is not relevant for mio, internal means the registry if I understand correctly

Each read does a reregister if it would block, so I fail to understand why that would be a bad thing for a peek to do it too. But I probably don't understand the implications of reregister, the name suggest it is idempotent.

Now moving forward if this is not the solution what is? Is it to only reregister on windows? Is it to not clear readiness on WouldBlock (that seems wrong)?

[Sytten]

PR is incorrect closing