rtu-usb: claim the HID interface, send full-length reports, allow disabling reset

[d01]

Updated after reading networkupstools/nut#2609 properly — see the note at the end. The original version of this PR removed the device reset outright, which was wrong of me.

Two bugs in the rtu_usb backend, plus an option needed because the existing
reset on open is fatal on one device. Found getting NUT's apc_modbus working
with an APC Smart-UPS X1500 (051d:0003, firmware "UPS 16.0").

1. The HID interface is never claimed for I/O

_usb_get_hid_descriptor() claims the interface just long enough to read the
report descriptor and then releases it. On a match, _modbus_rtu_usb_connect()
stores the handle and breaks without claiming anything, so every subsequent
interrupt transfer runs against an interface still owned by the kernel HID
driver: the OUT transfer is not delivered, and the device's input reports go to
usbhid rather than to us.

Now claimed for the life of the connection and released in
_modbus_rtu_usb_close().

2. Short interrupt OUT transfers are ignored

The report descriptor declares output report 0x90 as 63 bytes, but the send
path transfers payload_chunk_len + 1 — 7 bytes for a 6-byte request. This
firmware accepts the short transfer at the host-controller level and then
ignores it: no reply arrives, and the Modbus engine is left unresponsive until
the USB cable is reseated. Sending the full declared length, zero padded, makes
the identical request work.

The OUT transfer also passed timeout 0 (wait forever), so an unresponsive
endpoint blocked the caller indefinitely rather than returning an error — which
is how this bug presented, and made it much harder to find. Now finite.

3. modbus_rtu_usb_set_reset_on_open() — new, default unchanged

The reset in _modbus_rtu_usb_connect() is fatal on the Smart-UPS X1500. After
it, the device never services its interrupt OUT endpoint again, every register
read times out, and only physically reseating the USB cable recovers it. A
sysfs-level re-enumeration reproduces the same state; neither idle time nor
draining the endpoint helps. It also runs for every device on the bus before
the match callback is consulted.

I originally submitted this as "remove the reset". That was wrong: @EchterAgo
added it deliberately in #11, and explained why in
networkupstools/nut#2609 — it recovers devices whose framing has
desynchronised and which return stale data from earlier requests. I should have
read that thread before proposing to revert it, and I apologise for the noise.

So this keeps the reset on by default and adds a way to switch it off, rather
than changing behaviour for anyone else. Whether the default should change, or
whether this would be better as a device quirk or driven by detecting the
desync it targets, is a judgement call for someone with visibility across more
hardware than I have — happy to rework it whichever way you prefer.

Testing

Tested with NUT 2.8.4's apc_modbus, statically linked against this branch,
against an APC Smart-UPS X1500. With fixes 1 and 2 and the reset disabled, the
driver starts, reads the inventory block and polls cleanly — 5 minutes, zero
read failures, at the driver's stock 35 ms interframe delay. With either fix
missing, the inventory read at 516:636 fails immediately and the driver exits
with "Can't read inventory information from the UPS".

I have only this one model, so fixes 1 and 2 would benefit from review by
anyone with other rtu_usb hardware. The reset option should be behaviour-
neutral by construction, since the default path is unchanged.

Note on authorship

Developed with assistance from Claude (Anthropic); the commit carries a
Co-Authored-By trailer. All findings were verified on real hardware.