Remove component adapter and use the discovery API directly in the extension

[ericsnowcurrently]

From @karrtikr (in an internal work item):

There are certain places in the component adapter where we just need the kind. Instead we call resolveEnv which does much more than that, including running python. That leads to 10 times more activation time once we enable the component adapter, and various test failures: https://github.com/microsoft/vscode-python/pull/14914/checks?check_run_id=1520687479

Proposed soln: Add an option in the resolveEnv API to query only for kind.

[ericsnowcurrently]

Note that this only applies to before the first time we refresh the cache during each session. (Otherwise resolveEnv() is fine.)

For the extension the impact is solely during the activation. Furthermore, the caching locator should make this a non-issue, right? So if resolveEnv() is blocking extension activation then either something is wrong with the caching locator or we are trying to resolve an env that isn't already in the cache.

In the former case we should fix the locator. In the latter case, we should look at the specific circumstances under which this is a problem and determine if it is a problem in practice.

Regardless, we should be sure we have all the details of the situation and decide if it's really necessary before we expand the locator API. I'm not saying something like a "kindOnly" option to resolveEnv() (or a separate method) is the wrong thing to do. I'm just saying we should understand the source of the problem (impacting extension activation) before we plan on a solution.

[ericsnowcurrently]

FWIW, with the planned (slow) move to components, with the corresponding refactoring, I anticipate that eventually there will be nothing in extension activation which env discovery would block.

[karrtikr]

or we are trying to resolve an env that isn't already in the cache.

Yes, from the initial investigation, this was the cause. env is not stored in cache if running interpreterInfo.py for the env fails. So for example particularly with some windows store envs discovered by the old locator, that always fails. However you're right that once we slowly move to components and the old code is untangled, this may not be a problem.

[karrtikr]

This could mean that we may need to add an option in the resolveEnv API to query only for kind to handle scenarios like

vscode-python/src/client/pythonEnvironments/legacyIOC.ts

Line 191 in ad45050

return isCondaEnvironment(interpreterPath);

, as using resolveEnv is much more expensive than just identification.

[karrtikr]

Closing in favor of #20240 (comment).