Provide a flag to _not_ shutdown a kernel when deleting/patching a session

[GrossoDev]

Context

Currently, when deleting a session through the DELETE /api/sessions/{session_id} endpoint, the associated kernel also gets shutdown. This is apparently the expected behavior, since:

• The implementation of SessionManager.delete_session says this explicitly.
• It's detailed in the "delete session" workflow diagram.

This also happens when trying to PATCH /api/sessions/{session_id} with either a different kernel_id or kernel_name. The server looks for a running kernel with that ID or boots up a new one but always shuts down the old one. This also seems like expected behavior:

• The implementation of SessionHandler.patch is explicit about this.
• It's tested for in test_modify_kernel_name.

Problem

This is a problem when you have multiple sessions connected to the same kernel. For example, when one session tries to connect to a different kernel, the old kernel gets shut down, and this leaves the other session with a dead kernel.
The same happens if you try to delete one of the sessions: it takes down the kernel with it, and the other one is left dangling.

The API provides no way of telling the server that it should not kill the kernel, nor does it check that there are no other sessions connected to it before shutting it down.

Multiple sessions connected to the same kernel seems to be a feature of Jupyter, so its odd that this is the default behavior and the only option.

Proposed Solution

Add a boolean to these specific endpoints, called force_kernel_shutdown or similar. If True, it will shut down the kernel regardless of any other sessions connected to it. If false, it only shuts down the kernel if it's the last session still using it.
It should default to True if not specified, so that we can allow this new behavior without affecting existing codebases that expect the current one.

We would need to:

• Add a check of this boolean to SessionManager.delete_session
• And to SessionHandler.patch
• Add this boolean to the API endpoint DELETE /api/sessions/{session_id}
• And to PATCH /api/sessions/{session_id}
• Maybe detail this on the "delete session" flow diagram?
• Add new tests (current ones should still pass).

Additional context

There's an open issue from 2018 about this exact thing on the JupyterLab repo. This looks like the place to fix it.