Revisit code-server & vscode architecture

[jsjoeio]

One of our goals for 2022 is to reduce and remove as many of our custom patches as possible. Moving to a fork of VS Code was a huge step and prepared us for this move.

Now, we'd like to explore having some model (possibly with patches + fork) that makes it easier for us to identify which files changed in our fork are grouped together. Then we'd like to see which ones we can remove.

You can compare our changes to upstream here: microsoft/vscode@main...coder:main

Plan

This work will most likely be done by @jsjoeio (unless eng. dedicates bandwidth for @code-asher to work on code-server in Q1 2022).

Here is a rough plan for how we'd approach this:

Step 0: Spike tools for working with patches ✅

#4704

Step 1: Switch from yarn to a submodule 🚧

#4901

Step 2: Implement Patch Logic

The next step would be generating a diff and moving to a patch approach. This means the submodule would point to microsoft/vscode and we'd apply a patch as a build step.

1. generate diff
2. write functionality in one patch
3. then once that's merged in, split into individual patches (step 2)

Step 3: Split up patch logic

This will be the most difficult step because it requires the most context. @code-asher has agreed to help with this (be there for support), but giving that @jsjoeio should also have this knowledge, it may be best for Joe to do this.

1. break up diff into individual patches

The beauty of patches is there are partially self-documenting (name of files and add comments). So this context will live on and be available to everyone.

Other Notes

Here are some things we think we'll be able to remove when we switch to patches:

• undo most our formatting changes
• product.json changes can be added as a build step
• server greeting issue we can fix in build step