VxMark: Investigate spurious printer disconnects

[carolinemodic]

In the QA for mk14 we saw some spurious printer disconnects, also impacting other vxsuite applications. We increased a timeout delay const but Ben still reported seeing this issue once. In mk15 a printer disconnect will cause an alarm and the usb port to become disabled so it is more important that we don't have spurious disconnects on print.

cc @adghayes

[carolinemodic]

some dicussion related to this task here: https://docs.google.com/document/d/1SAQzoSt7AjwThawx-mRTToen7NS85BT7QylvKm6glrU/edit?usp=sharing

[adghayes]

adding some notes from my history with this issue...

the printer is disconnecting because the CUPS server is not seeing it as a connected device. we look for connected devices via the CUPS server in the device_uri.ts helper. the CUPS server has various limitations, though, and it's possible that the USB device is always detected and the only blip is on the CUPS. that will require some experimentation.

if the USB device is consistently detected, then we could instead base the alarm feature off of that USB device's presence, using is_device_attached.ts, which is how we detect the presence of the central scanners.

there's a larger possible change in which we base the whole printer status in libs/printing off of that USB device, but that opens up larger questions and could introduce new bugs:

• what happens to print jobs that get sent while the configuration on the CUPS server blips? do we need special handling?
• what happens to the IPP rich status polling while the configuration on the CUPS server blips? do we need special handling?

of course, all of this is moot if the blip extends all the way down to the USB device level