Emit connectionstatechange events

[ethanlook]

This adds connectionstatechange events to the RobotClient such that a consumer only has to listen to one thing to get all of the connection events.

Example:

let connectionState = 'disconnected';

// Need to mark 'connecting' and 'connected' by yourself on the initial connection since we can't listen to events until createRobotClient resolves.
connectionState = 'connecting';
const machine = VIAM.createRobotClient({ ... });
connectionState = 'connected';

machine.on('connectionstatechange', (event) => {
  connectionState = (event as { eventType: MachineConnectionState }).eventType;
});

To best see this in action, check out the follow-up PR to add a new vanilla example for using the robot client. I used this for testing during local development. (The existing vanilla example uses the Viam client.)

1. ➡️ Emit connectionstatechange events #299
2. Update vanilla example to use Vite + TS app for robot client #300

Change log

• Update the possible MachineConnectionEvents: connecting | connected | disconnecting | disconnected
  • I got rid of reconnected. AFAICT it was just used internally, but please let me know if that assumption is false. Because of how reconnect logic is structured using connect(), it would be messy to emit a different event during reconnecting and reconnected.
• For connect() - emit connecting at start and connected if successful. disconnected is still emitted when there is a failure.
• For disconnect() - emit disconnecting at start and disconnected if successful.
  • disconnecting -> disconnect isn't humanly perceivable under the conditions I was testing in, but I think it's good practice to emit to the consumer
• Expose connectionstatechange event on RobotClients

[stuqdog]

A couple minor things (no need to rerequest review) otherwise lgtm!

[stuqdog]

(q) is this necessary, given that we've set this.on(eventType ...) above?

Same with other this.emit calls below.

[njooma]

Similar (q): why not just emit the connectionstatechange here, rather than emitting this event, then catching it and re-emitting?

[ethanlook]

This is actually emitting the source event, signaling disconnect is starting. The this.on(eventType, ...) above re-emits the event with the name connectionstatechange. What this means is the consumer can choose which event they want to listen to - if they care about all connection events, they can set up a robotClient.on('connectionstatechange', ...) event handler. If they only want to listen to disconnected events, they can just set up a robotClient.on('disconnected', ...) handler.

We don't want to just emit connectionstatechange here because we would need to emit the connectionstatechange anywhere a disconnecting, disconnect, connecting, or connected event is emitted. By catching and re-emitting, we don't need to remember to also emit connectionstatechange everywhere.

[ethanlook]

This is actually emitting the source event, signaling disconnect is starting. The this.on(eventType, ...) above re-emits the event with the name connectionstatechange. What this means is the consumer can choose which event they want to listen to - if they care about all connection events, they can set up a robotClient.on('connectionstatechange', ...) event handler. If they only want to listen to disconnected events, they can just set up a robotClient.on('disconnected', ...) handler.

We don't want to just emit connectionstatechange here because we would need to emit the connectionstatechange anywhere a disconnecting, disconnect, connecting, or connected event is emitted. By catching and re-emitting, we don't need to remember to also emit connectionstatechange everywhere.