Improve kernel restart logic to reestablish ZMQ connection when a kernel is restarted with new ports

[skukhtichev]

This proposal is based on jupyter/jupyter_client#348.

This proposal defines the logic for creating new ZMQ connection without closing existing websocket connection if a kernel was restarted with new ports (e.g. when the kernel is not responding during initial startup).
The following changes were added to the on_kernel_restarted function:

• kwargs support
• newports parameter from kwargs used if it is defined. If the parameter is not in kwargs set it to False
• If newports == True then existing ZMQ connection to the kernel is closed and new stream with updated ports is opened.
• If newports == False then client is notified that the kernel was restarted
  This proposal solves the issue described in Kernel is not restarted with new ports if the kernel dies after the polling is started jupyter_client#347

[takluyver]

This makes sense; I've suggested a couple of simplifications. Based on my ideas for the corresponding jupyter_client PR, this will probably need an extra change in (I guess) notebook.services.kernels.kernelmanager to tell the restarter that we can handle new ports.

[takluyver]

I think this can be simplified:

def on_kernel_restarted(self, newports=False):
   ...

[takluyver]

I can see this is copied from the open() method, but I don't think create_stream can actually raise HTTPError. Maybe it could at some point in the past. @minrk any ideas?

[minrk]

I think you're right. My guess is there used to be code in there where we were retrieving the kernel, which could raise 404, etc. Or it was just a mistake and this should have been Exception all along, which is what it should be now.

[blink1073]

Closing this one as out of date, since a lot has changed in juptyer_client since.