Path resolver API

[krassowski]

This patch demonstrates the scaffold of the new path resolver API endpoint proposed in #1280.

This depends on a sibling PR jupyter/jupyter_client#1005

Questions:

• should I use self.kernel_manager or self.multi_kernel_manager? (these are not well documented in code)

In future we could include an entry point (e.g. traitlet) to define additional scopes (e.g. from remote file systems), but this is out of scope for this PR which focuses on distinguishing between a path from kernel and server.

[krassowski]

@meeseeksdev tag enhancement

[lumberbot-app]

Awww, sorry krassowski you do not seem to be allowed to do that, please ask a repository maintainer.

[krassowski]

Can a repository maintainer add labels to my pull requests or configure lumberbot to make it usable? It helps to see what is the CI status and reduces number of distracting spam emails about failure status.

[blink1073]

I'm afk for the next few days but would merge such a PR. 😃

[krassowski]

Marking this as ready-for review because:

• Path resolution by kernel manager and providers jupyter/jupyter_client#1005 is ready,
• I did not get much feedback on Exposing kernel contents (file system) via comms jupyter/jupyter_client#1006 so I assume this is not something folks would have capacity to review right now (and that appears to be a rather large feature which would benefit some upfront planning).

However, if the decision is to go with jupyter/jupyter_client#1006 and close this PR (along with jupyter/jupyter_client#1005) I would totally understand this.

[krassowski]

Another use case for this API is jupyterlab/jupyterlab#16235 - we currently cannot reliably reconcile the files returned by the debugger with the file system.