Clean up cli build

[joaomoreno]

There are a few strange choices in the cli build infrastructure:

• cli/build.rs reaches out into ../build/azure-pipelines
• cli/build.rs behaves differently whenever vscode-distro is a sibling folder of vscode
• build/azure-pipelines/cli/prepare.ts reaches out to the quality folder

As rules of thumb:

• I should be able to just run cargo build and have an OSS build of the CLI, independent of the fact that I have a vscode-distro folder as a sibling of vscode.
• After mixing in distro, no other component in our build infrastructure should ever reach into the quality folder.
  • If there is a reason for the Insider CLI (eg.) to know specific details about the stable and exploration qualities, this should be information contained in Insider's product.json itself, not done via some build magic which reaches out to other qualities product.json files.
• There should be zero build components reaching out to build/azure-pipelines. Only Azure Pipelines should reach in there.

[connor4312]

The nice thing about having build.rs look for vscode distro, is that it's then easy to locally build a CLI that supports tunnel access, which requires quality information from distros to function.

If there is a reason for the Insider CLI (eg.) to know specific details about the stable and exploration qualities, this should be information contained in Insider's product.json itself

This is currently necessary because, for example, the "stable" build of the CLI is able to launch Insiders servers when connected to from insiders.vscode.dev or an Insiders quality on desktop. Likewise, in its 'redirection' logic, the CLI can be configured to open a chosen quality e.g. ./code --quality [stable|insiders|exploration] .. You could argue this shouldn't be the case, but while they are, then we either need to pull this information from all qualities or duplicate all these things in each product.json--and make sure to keep them in sync!

vscode/cli/src/constants.rs

Lines 85 to 103 in d4d0d2a

	/// Map of quality names to arrays of app IDs used for them, for example, `{"stable":["ABC123"]}`
	pub static ref WIN32_APP_IDS: Option<HashMap<Quality, Vec<String>>> =
	option_env!("VSCODE_CLI_WIN32_APP_IDS").and_then(|s| serde_json::from_str(s).unwrap());
	/// Map of quality names to desktop download URIs
	pub static ref QUALITY_DOWNLOAD_URIS: Option<HashMap<Quality, String>> =
	option_env!("VSCODE_CLI_QUALITY_DOWNLOAD_URIS").and_then(|s| serde_json::from_str(s).unwrap());
	/// Map of qualities to the long name of the app in that quality
	pub static ref PRODUCT_NAME_LONG_MAP: Option<HashMap<Quality, String>> =
	option_env!("VSCODE_CLI_NAME_LONG_MAP").and_then(|s| serde_json::from_str(s).unwrap());
	/// Map of qualities to the application name
	pub static ref APPLICATION_NAME_MAP: Option<HashMap<Quality, String>> =
	option_env!("VSCODE_CLI_APPLICATION_NAME_MAP").and_then(|s| serde_json::from_str(s).unwrap());
	/// Map of qualities to the server name
	pub static ref SERVER_NAME_MAP: Option<HashMap<Quality, String>> =
	option_env!("VSCODE_CLI_SERVER_NAME_MAP").and_then(|s| serde_json::from_str(s).unwrap());

I didn't/don't know of a reason why the build shouldn't be able to know about qualities other than the one currently being built, so the former option seemed the better choice.