Use VS Code packaging for releases (#7721)

* Allow setting the VS Code build target

For the NPM package (and tests, at least for now), we will still use
linux-x64, but this is going to allow using the platform build targets
for our standalone releases so we can avoid having to copy all the
packaging steps (like cleaning up modules).

This does mean that the NPM package when installed will be missing those
cleanup steps.  Possibly we can try to break out the packaging step into
a something that can be ran standalone (which will also require
installing dev dependencies like gulp) but not sure how much work this
would be.

* Preserve dependencies for e2e tests

To avoid having to install them again.

Also moved an env block to the root of the  job.

* Refactor releases to use VS Code packaging

Instead of building the linux-x64 package, stripping the modules, then
installing them again, we build the correct target and use the modules
as they are.

This means we do not have to copy all the post-processing steps like the
ones that delete unnecessary modules.

For the NPM package we still publish the linux-x64 package (without
modules of course).  This means npm installations do not get that same
post-processing.

Another advantage of this is that we can run the release immediately
without having to wait for the build step, or on a commit that no longer
has a build artifact, since they all build individually now.  We could
try sharing the core-ci build step, but leaving that alone for now.

I also converted the macOS jobs into a matrix.

Deleted the CI readme because it was out of date and seemed to just
repeat what should be described in the scripts anyway.

Removed a section about Homebrew since we do not maintain that anymore.

It looks like there is no need to symlink node_modules.asar anymore.

ci/build/build-vscode.sh

@@ -6,33 +6,32 @@ set -euo pipefail
 # MINIFY controls whether a minified version of vscode is built.
 MINIFY=${MINIFY-true}
 
-delete-bin-script() {
-  rm -f "lib/vscode-reh-web-linux-x64/bin/$1"
-}
-
-copy-bin-script() {
-  local script="$1"
-  local dest="lib/vscode-reh-web-linux-x64/bin/$script"
-  cp "lib/vscode/resources/server/bin/$script" "$dest"
-  sed -i.bak "s/@@VERSION@@/$(vscode_version)/g" "$dest"
-  sed -i.bak "s/@@COMMIT@@/$BUILD_SOURCEVERSION/g" "$dest"
-  sed -i.bak "s/@@APPNAME@@/code-server/g" "$dest"
+fix-bin-script() {
+  local script="lib/vscode-reh-web-$VSCODE_TARGET/bin/$1"
+  sed -i.bak "s/@@VERSION@@/$(vscode_version)/g" "$script"
+  sed -i.bak "s/@@COMMIT@@/$BUILD_SOURCEVERSION/g" "$script"
+  sed -i.bak "s/@@APPNAME@@/code-server/g" "$script"
 
   # Fix Node path on Darwin and Linux.
   # We do not want expansion here; this text should make it to the file as-is.
   # shellcheck disable=SC2016
-  sed -i.bak 's/^ROOT=\(.*\)$/VSROOT=\1\nROOT="$(dirname "$(dirname "$VSROOT")")"/g' "$dest"
-  sed -i.bak 's/ROOT\/out/VSROOT\/out/g' "$dest"
+  sed -i.bak 's/^ROOT=\(.*\)$/VSROOT=\1\nROOT="$(dirname "$(dirname "$VSROOT")")"/g' "$script"
+  sed -i.bak 's/ROOT\/out/VSROOT\/out/g' "$script"
   # We do not want expansion here; this text should make it to the file as-is.
   # shellcheck disable=SC2016
-  sed -i.bak 's/$ROOT\/node/${NODE_EXEC_PATH:-$ROOT\/lib\/node}/g' "$dest"
+  sed -i.bak 's/$ROOT\/node/${NODE_EXEC_PATH:-$ROOT\/lib\/node}/g' "$script"
 
   # Fix Node path on Windows.
-  sed -i.bak 's/^set ROOT_DIR=\(.*\)$/set ROOT_DIR=%~dp0..\\..\\..\\..\r\nset VSROOT_DIR=\1/g' "$dest"
-  sed -i.bak 's/%ROOT_DIR%\\out/%VSROOT_DIR%\\out/g' "$dest"
+  sed -i.bak 's/^set ROOT_DIR=\(.*\)$/set ROOT_DIR=%~dp0..\\..\\..\\..\r\nset VSROOT_DIR=\1/g' "$script"
+  sed -i.bak 's/%ROOT_DIR%\\out/%VSROOT_DIR%\\out/g' "$script"
 
-  chmod +x "$dest"
-  rm "$dest.bak"
+  chmod +x "$script"
+  rm "$script.bak"
+}
+
+copy-bin-script() {
+  cp "lib/vscode/resources/server/bin/$1" "lib/vscode-reh-web-$VSCODE_TARGET/bin/$1"
+  fix-bin-script "$1"
 }
 
 main() {
@@ -108,12 +107,8 @@ main() {
 EOF
   ) > product.json
 
-  # Any platform here works since we will do our own packaging.  We have to do
-  # this because we have an NPM package that could be installed on any platform.
-  # The correct platform dependencies and scripts will be installed as part of
-  # the post-install during `npm install` or when building a standalone release.
   npm run gulp core-ci
-  npm run gulp "vscode-reh-web-linux-x64${MINIFY:+-min}-ci"
+  npm run gulp "vscode-reh-web-$VSCODE_TARGET${MINIFY:+-min}-ci"
 
   # Reset so if you develop after building you will not be stuck with the wrong
   # commit (the dev client will use `oss-dev` but the dev server will still use
@@ -122,7 +117,7 @@ EOF
 
   popd
 
-  pushd lib/vscode-reh-web-linux-x64
+  pushd "lib/vscode-reh-web-$VSCODE_TARGET"
   # Make sure Code took the version we set in the environment variable.  Not
   # having a version will break display languages.
   if ! jq -e .commit product.json; then
@@ -131,15 +126,28 @@ EOF
   fi
   popd
 
+  # Set vars and fix paths.
+  case $OS in
+    windows)
+      fix-bin-script remote-cli/code.cmd
+      fix-bin-script helpers/browser.cmd
+      ;;
+    *)
+      fix-bin-script remote-cli/code-server
+      fix-bin-script helpers/browser.sh
+      ;;
+  esac
+
+  # Include bin scripts for other platforms so we can use the right one in the
+  # NPM post-install.
+
   # These provide a `code-server` command in the integrated terminal to open
   # files in the current instance.
-  delete-bin-script remote-cli/code-server
   copy-bin-script remote-cli/code-darwin.sh
   copy-bin-script remote-cli/code-linux.sh
   copy-bin-script remote-cli/code.cmd
 
   # These provide a way for terminal applications to open browser windows.
-  delete-bin-script helpers/browser.sh
   copy-bin-script helpers/browser-darwin.sh
   copy-bin-script helpers/browser-linux.sh
   copy-bin-script helpers/browser.cmd