Investigate ways to improve activation time

[bwateratmsft]

We've just done a significant amount of improvement to code loading time. We should also see what can be done about activation time.

At the time of writing, for 1.6.0 the avg activation times are 278 ms for Linux, 388 ms for Mac, 541 ms for Windows. I'd like to get Windows (and the rest) below 200 ms if at all possible.

[bwateratmsft]

I've done some investigating. On my (Windows) machine, the biggest delay is from docker context ls, unsurprisingly; about 600ms. Other slowish points were the calls to setVsCodeContext (about 20ms each), loading the Dockerode API (obviously needed otherwise it's less-efficient code loading time), and the filesystem checks for ~/.docker/....

We can make the calls to setVsCodeContext no longer wait. In fact we can probably make the entire loading of DockerContextManager not wait, since anything actually using it will be held up by the lazy-loading anyway. If we do this, at least the language server and debug/etc. providers will be set up more quickly.

Also worth considering is trying to call the Docker SDK to load the contexts if possible, however it does not include the host at this time which is needed to make Dockerode work.

[bwateratmsft]

The activation time is dominated by several things:

Things we can maybe improve:

• Get Docker ID (this is already a one-time penalty, it's cached from then on)
• Filesystem checks for Docker context paths
• Setting the VSCode contexts
• Don't wait on Docker context loading??

Things we cannot improve at this time:

• Docker CLI call for Docker contexts
• Dockerode client loading (we removed it from code loading to put it here as lazy, overall it's a win)

[bwateratmsft]

This fix has now been released in 1.8.0.