Fix (RTU USB) failure to select() an invalid file descriptor

[jimklimov]

Implementation of new libusb-based USB RTU for libmodbus, as proposed by @EchterAgo as part of networkupstools/nut#2063 solution, involves direct libusb API communications in the new backend. As such, there is normally no file descriptor to select() for incoming data, as is the case with serial port or a network socket (TCP RTU).

After investigation done in networkupstools/nut#2609 and related tickets (networkupstools/nut#2289, networkupstools/nut#2732) I am convinced that the technical issue is in this backend never initializing ctx->s so it remains -1 from common allocation. The (generally platform-defined) implementations of FD_SET et al expect non-negative integers as file descriptor numbers:

An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior. Moreover, POSIX requires fd to be a valid file descriptor.

While some platforms used for initial development apparently were lax about this for whatever reason, on others later on this use of -1 misfired visibly; I suspect they were made more secure about checking for memory errors (and here we could have had an array underflow, depending on FD_XXX implementation as e.g. macros).

This PR proposes a couple of changes:

• Avoid using ctx->s == -1 in the FD set for select() (just in case, do pass that logical code path - e.g. if the system imposes some default file descriptors to consider anyway), and do not return from that code path if it failed and we had ctx->s == -1.
• Also use libusb-1.0 API (if available in the version we build libmodbus against) to check if the libusb context reports any file descriptors for polling, as explored in Use libusb-1.0 report of pollfd's in NUT main loop nut#2747 -- see https://libusb.sourceforge.io/api-1.0/group__libusb__poll.html#ga54c27dcf8a95d2a3a03cfb7dd37eae63 and https://libusb.sourceforge.io/api-1.0/structlibusb__pollfd.html; if there is exactly one FD reported this way, use it as ctx->s.

These changes were tested in networkupstools/nut#2609 (comment) which collected the device data and did not crash like before.

NOTE: The test Got a list of 3 libusb file descriptors to poll and so did not assign any to ctx->s; this may need more exploration - what those FDs are and if each should be polled. Maybe change the single ctx->s to an array (or to keep code of other RTU's largely unmodified, add the array to backend or even common ctx structure, and use it for select() if e.g. ctx->s==-2)?