NUT swarm stress testing (WIN32): `upsd` should prepare an array of all handles ready to talk, and iterate it like in POSIX code path

[jimklimov]

Currently the POSIX code path in upsd::mainloop() uses poll() to highlight an array of file descriptors ready for immediate interaction, and iterates that array before the next loop for a new set of file descriptors (drivers, clients, listeners...) to check the status of.

The Windows code path relies on WaitForMultipleObjects() which takes an array of handles and returns the array index of the first handle ready to talk, then we interact with that one handle and repeat the whole mainloop() from scratch.

This RFE is about using a series of WaitForMultipleObjects() with a sliding window (to restart from the last highlighted handle, checking up to sysmaxconn handles at a a time), so we can prepare the array of all known active handles and then walk it in the sub-loop before repeating the mainloop() from scratch -- like we do in POSIX code path. This might be the less resource-intensive approach, and should preclude an early-listed extremely active connection from starving all others of their time-share of the server's attention (this point is generally stressed in #3365).

Bonus aspect: maybe as a result of this, the code base for POSIX and WIN32 builds can be de-duplicated (if there would be replaceable implementations for polling of a huge array of FD/HANDLE instances, and checking their status (incoming, closed, etc.) and so we would simplify its maintenance and evolution.

See also:

• Pushing Nut on Windows.... #3302
• upsd: chunk the MAXCONN-sized array processing into several smaller "sysmaxconn"-sized polls as needed #3303 and upsd: Revise chunked select from a swarm of client or driver connections #3367
• NUT swarm stress testing: fall back to smaller chunks if later ones are starved of attention, or ulimit is neigh #3365
• NUT swarm stress testing: revise cleanup of disconnected sockets #3366