ark: Behaviour with redundant `open_comm` messages

[lionel-]

When this happens, positron functionality is limited. We no longer receive set-console-width events for instance.

[R] 2024-01-03T15:26:16.633372000Z [ark-unknown] ERROR crates/ark/src/frontend/frontend.rs:66: Error receiving Positron event; closing event listener: RecvError

A RecvError indicates the channel is closed, which can only occur if all senders have been dropped, but that doesn't appear to be the case. Puzzling.

This unexpected channel closing is what caused the infinite logs issue that was fixed in https://github.com/posit-dev/amalthea/pull/176

[lionel-]

This happens when the frontend comm is started twice in a row. Which happens when the heartbeat setting of the jupyter adapter is set to 0. In that case, a timeout bug causes the Jupyter runtime to briefly enter the Offline state. When we switch back to Ready, some initialisation code recreates of the frontend and help comms.

I think we need a few fixes here:

• In the Jupyter adapter, a heartbeat setting of 0 seconds shouldn't cause a runtime to enter the offline state
• Ark should be resilient to getting redundant comm_open messages. And if already open, we probably should reuse existing ones?
• On the main thread, getting back to Ready after a disconnect probably shouldn't cause a recreation of widget clients? Or alternatively we let the main thread call createClient() again but we change the Jupyter adapter to reuse existing clients if they exist. Some precautions then need to be taken during client init.

I lean towards making createClient() idempotent in both ark and jupyter-adapter and reuse existing clients if called multiple times. To actually recreate a client, you'd need to call removeClient() first. WDYT @jmcphers?