Resolve crash in xsbug-log when using Workers

[cmidgley]

When using mcconfig -dl (xsbug-log) with a program that uses Worker, each worker will make a new connection to xsbug-log. When the worker is done, it tears down the connection and xsbug-log does not have handlers for the connection reset and it crashes with the following:

node:events:497
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:218:20)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:169:8)
    at emitErrorCloseNT (node:internal/streams/destroy:128:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -4077,
  code: 'ECONNRESET',
  syscall: 'read'
}

This PR adds event handlers for the error and close events, and cleanly unpipes from Saxaphore, thereby resolving the issue.

[phoddie]

I use xsbug-log reasonably often but apparently not with workers.

On macOS, the error you report happens sometimes, but not always. Your change eliminates that. I tested using $MODDABLE/examples/base/worker. That gets through some iterations (400 to 1000) but eventually hangs. The hang doesn't happen with xsbug. And... the only way to get things back to a normal state is to detach/reattach the device.

We can take the PR. it is an improvement (thank you!). But... some mystery remains.

[cmidgley]

I just tried $MODDABLE/examples/base/worker on sim to around 80,000 cycles and on ESP32 for 20,000 cycles without any problems (on my Windows system).

When it fails for you, does it just hang or is there any error message? Perhaps get it to fail and try telnet localhost 5002 - it should connect to xsbug-log if it is listening. If it doesn't connect, perhaps check if the process is still running or if it terminated? As you know all too well, not being able to reproduce the failure makes it hard to debug... but I'm glad to try!

[phoddie]

Yeah, I imagined it was probably reliable on your Windows set-up. Thanks for running the extended test. I realized that yesterday I was testing using the direct USB connection. That isn't quite as reliable as serial. Using serial instead works perfectly reliably here -- 12,000 cycles and counting.

This change is good. The USB failures could be anywhere -- USB driver on the device, USB driver on macOS, and on up the stack. That's not a project that needs to be tackled at the moment.