Add support for Kernelspec caching

[kevin-bates]

This pull request adds support for Kernel Specification caching. Since various applications tend to poll for kernelspecs, and EG needs to support multiple such applications, it makes sense to route kernelspec requests through a caching facility, which defers to the configured KernelSpecManager if the kernelspec is not found.

This implementation uses watchdog to monitor the directory hierarchies containing kernelspecs. If new kernelspecs are added that exist in non-monitored directories a cache miss will ensue - triggering the monitoring of the newly discovered directory.

In current trials, this appears to have about a 70% performance increase in kernelspec retrievals.

For now, the cache is disabled by default. In EG 3.0 (or sooner?) we will enable caching to be on by default. Until then, it can be enabled via CLI option --KernelSpecCache.cache_enabled=True or env EG_KERNELSPEC_CACHE_ENABLED=True.

• Update configuration section of docs
• Copy resource handler to EG and use cache to handle those requests (though static file handling will still work as today)

[lresende]

Overall it looks good, I had a couple of question around some corner cases.

Having said that, I believe this solves the overhead load on the server-side, but the contents of the kernelspec still go over the network, and maybe we could add support for ETAGS on a subsequent PR.

[kevin-bates]

Correct, this only addresses the redundant gathering of kernelspecs on the server. I wasn't aware of ETags, but that makes total sense - good idea. I'm assuming the browser would handle the 304 response, etc. and that client applications wouldn't need to change.

[kevin-bates]

So my last commit removed f strings thinking that was preventing python 3.5 support, but it looks like PosixPath handling is an issue as well. Sigh. I think we should look at dropping 3.5 and perhaps moving to jupyter_server as our base implementation (and away from notebook). This probably implies setting up a 2.x branch and this functionality would be part of a 3.0 release.

What do you think?

[kevin-bates]

Here's a gist to add code to create missing kernel_dir entries (rather than issue a warning) if we want that functionality: https://gist.github.com/kevin-bates/45ddbc94f49f5415bf2985394dbf6925