With the introduction of the new remote finder and server picker experience, we might want to revisit how we are registering kernels from remote uris and what we store in ServerUriStorage

• ServerUriStorage can contain following info
  • url list
    • user provided server urls
    • third party contributed server urls
    • local when users explicitly set the server to None from the server picker
  • currentServerId referring to the currently picked entry
  • localOnly referring to if we should connect to local only (❓)
• Traditional workflow
  • LocalKernelFinder contributes all local kernels
  • RemoteKernelFinder checks ServerUriStorage#currentServerId and decides if/how to detect kernel specs/sessions
    • If the selected entry in ServerUriStorage is local, then it doesn't attempt to scan kernel specs/sessions.
• New workflow
  • UniversalRemoteKernelFinderController creates a UniRemoteKernelFinder for all entries
  • Each UniRemoteKernelFinder follows the same logic as RemoteKernelFinder, if its uri is local, it contributes empty kernel specs/sessions.

It would be great if we can move local out of the ServerUriStorage and we can simply the RemoteKernelFinder ctor and registrations into

• ServerUriStorage only holds server uri infos
• Traditional remote kernel finder controller
  • Hold the currentSelectedUri info
  • Register/dispose remote kernel finder per currentSelectedUri update
• New remote kernel finder controller
  • Register/dispose all remote kernel finders per ServerUriStorage#getUris

cc @IanMatthewHuff @DonJayamanne