[code] preview version for testing

[akosyakov]

We need to use VS Code before giving it to end users. It would be good to allow deploying a new version without switching all users to it.

[csweichel]

We should revive the feature preview flag and use it for this decision. It's still in the database, and we could re-set it for Gitpod folks only.

[csweichel]

To do this we'd pin the stable version and have the components/ide/code component build the "next generation".
We'd need an automatic mechanism to "promote" past builds to the stable build though. I reckon we could build something using prow.

[csweichel]

/schedule

[csweichel]

During an offline discussion with @geropl we outlined the following solution:

• in the server IDE config we introduce code-preview which is set the current Code image build (the very same that previously set the code alias)
• we make the "VSCode Preview" a selectable IDE on the dashboard, much like Theia
  
• the VS Code version that sets the default code alias is pinned to a gitpod-io/gitpod commit in a file in the repository.

Benefits:

• this solution relies predominantly on concepts we already have
• GItpod's versioning/config remains self-contained in the repository
• we don't need any exceptions for any of the environments (e.g. no special prod deployment)
  • corollary: also works for self-hosted
• we don't need to add in the "Feature Flag" mechanism to the new dashboard just yet

Maybe downside:

• the additional VS Code (Preview) may be confusing for users

/cc @svenefftinge @gtsiolis WDYT about the "VS Code Preview" idea?

[akosyakov]

We can call it insiders and it can be used for early adapters. It is the same with desktop VS Code and should not be confusing.

[JanKoehnlein]

/assign

[JanKoehnlein]

The PR has been rolled back as it was breaking deployment (while it was working fine in the preview env).

The (suspected) cause is that the code element from the values.yaml in gitpod-io is overwritten and not merged in the deployment by the code element in the values.yaml that is generated from the image manifests during deployment, thereby deleting the additional stableVersion property.

We should rather fix/simplify this than forcing workarounds on gitpod-io, so I'll add the very same PR to leave it for fixing in gitpod-com