Add HidApi::reset_devices & HidApi::add_devices

[Sainan]

Enumerating all devices is rather undesirable, because it may require communicating with each device at each refresh, which is made even worse by the fact that some mice interupt their input for this communication. Combine that with an app that refreshes devices regularly and you've got very laggy mouse input.

These new APIs gives apps an alternative to:

hid.refresh_devices()?;

With more narrow scoping:

hid.reset_devices()?;
hid.add_devices(0x31E3, 0)?;
hid.add_devices(0x03EB, 0xFF01)?;
hid.add_devices(0x03EB, 0xFF02)?;

[ruabmbua]

Hi, thanks for the PR. This unfortunately breaks some of the other backends we have.

Also, can you maybe describe your situation, where the scanning for devices actually caused issues? E.g. what platform, and maybe what you do in the code. For enumerating the devices in e.g. the linux hidraw backend, it should not be necessary to actually talk to the device in question. The hid report descriptor is fetched from the device by the kernel when its attached, then fixed up and stored inside the kernel. When getting the report descriptor from userspace, its just passed from the kernel to the userspace app, even if you do it multiple times.

[Sainan]

@ruabmbua The issue was reported here among other places: https://github.com/WootingKb/wooting-analog-sdk/issues/40

It occurs specifically on Windows due to the underlying hidapi C library calling HidD_GetProductString and HidD_GetSerialNumberString as part of the device enumeration, which may require talking to the device as described.

[Sainan]

Workflows should now all succeed as of the latest commit.

[ruabmbua]

Thank you, will merge this now. I will wait a bit for crates.io release, since I want to do my tests before.