Better handling of closed stream errors

[akberenz]

Addresses the issue in #1300 where streams will continue to attempt sending data to a closed stream until explicitly closed.

[tresf]

@Vzor- I thought we had gracefully handled this in our upstream PR, but somehow I'm able to crash the app here if I call usb.close(). gary-rowe/hid4java#153.

I'm leaving this comment in the source code for now as a future warning.

Crashing it's pretty easy, just change usb.setStreaming(false) to usb.close() and close the tab while the device is streaming.

[tresf]

Testing this... sadly, the ClosedChannelException is being wrapped in an IOException which is causing the explicit catches to not fire. Investigating...

[ERROR] 2024-12-03T13:12:37,022 @ qz.ws.PrintSocketClient:834
	Could not send message
java.io.IOException: java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.util.FutureCallback.block(FutureCallback.java:163) ~[jetty-util-10.0.22.jar:10.0.22]
	at org.eclipse.jetty.util.FutureCallback.block(FutureCallback.java:139) ~[jetty-util-10.0.22.jar:10.0.22]
	at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBlocking(JettyWebSocketRemoteEndpoint.java:191) ~[websocket-jetty-common-10.0.22.jar:10.0.22]
	at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendString(JettyWebSocketRemoteEndpoint.java:52) ~[websocket-jetty-common-10.0.22.jar:10.0.22]
	at qz.ws.PrintSocketClient.send(PrintSocketClient.java:828) ~[production/:?]
	at qz.ws.PrintSocketClient.sendError(PrintSocketClient.java:768) ~[production/:?]
	at qz.ws.PrintSocketClient.processMessage(PrintSocketClient.java:375) ~[production/:?]
	at qz.ws.PrintSocketClient.lambda$onMessage$0(PrintSocketClient.java:171) ~[production/:?]
	at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onOutgoingFrame(WebSocketSessionState.java:184) ~[websocket-core-common-10.0.22.jar:10.0.22]
	at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.sendFrame(WebSocketCoreSession.java:514) ~[websocket-core-common-10.0.22.jar:10.0.22]
	at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBlocking(JettyWebSocketRemoteEndpoint.java:190) ~[websocket-jetty-common-10.0.22.jar:10.0.22]
	... 6 more

[tresf]

Testing this... sadly, the ClosedChannelException is being wrapped in an IOException which is causing the explicit catches to not fire. Investigating...

I think this is fixed via f0e3754.