Do not enter kernel ready state until after kernel info reply

[jmcphers]

Currently, Kallichore enters the kernel Ready state as soon as it gets a heartbeat from the kernel. This is overly optimistic; Positron's Jupyter Adapter has a more pessimistic behavior wherein it uses kernel info requests to probe the kernel for readiness, which is a more reliable way to see whether the kernel is actually open for business. Details here:

posit-dev/positron#2207

Positron always sends a kernel info request when it starts the kernel. If we are sending a request from Kallichore internally too, that feels a little sloppy. Some possible resolutions:

• the "Start Kernel" API could resolve with the kernel info request's payload, so that Positron doesn't have to send another request to get the data
• we could cache the kernel's response for a short period of time so that we don't have to ask for it again
• we could just live with two requests, it's not that bad

We could also use the initial kernel info request to populate the initial input/continuation prompt fields (see #10).

Also note that some kernels support a way to detect a ready state on IOPub. We can't rely on this, though, so we need the above scheme for kernels that don't (pretty much all of them right now?). See #1.

[lionel-]

For kernels that don't support JEP 65 it's still important to detect readiness on IOPub, otherwise it's possible to miss out on IOPub messages. This happens when Shell is connected but IOPub isn't. The client sends Shell request but isn't able to receive all associated IOPub output, including Busy/Idle messages.

So Positron took the approach of sending a kernel-info-request on startup and listening for IOPub Status messages while the reply comes in. If we get a reply but no IOPub Status message, it means IOPub is still not connected. In that case keep sending new kernel-info-requests until we get an Idle status. Once we get one, switch to Ready.

[DavisVaughan]

Yea I think reimplementing the repeated kernel-info-request logic we have in Positron that @lionel- describes above is definitely going to be something kallichore still needs to do for kernels that don't support JEP 65.

Without this, it is unfortunately quite common to think that IOPub is fully subscribed when it actually isn't yet