Strategize quality improvements for the Web IDE Terminal/Environment

Description

Context: The Web IDE Terminal feature is in an experimental phase. We're taking this time (and issue) to evaluate that we're on the right track. We've hit some impressive function requirements, but there are some significant quality requirements which might require rethinking our approach.

Problem to Solve

1. Startup performance.
   • Running locally, this can take anywhere from 5-10+ seconds.
2. Availability.
   • Right now the Web IDE Terminal is only available to GitLab Ultimate and project maintainers.
   • This is partially because of it's experimental phase. We are still observing how the system behaves under a production load.
3. Coupling to CI.
   • Changes to CI policy could (and have) cause Web IDE Terminal regressions.
   • There was a recent change in CI where “cancelled” pipelines could not be “retried”. This caused a regression in Web IDE Terminal.
   • We run a version of the .gitlab-ci.yml file that doesn’t support everything CI does, and supports some things it doesn’t.
4. Required setup.
   • Some Web IDE Terminal features need kubernetes runners.
5. Economic.
   • Does the Web IDE Terminal make economic sense for us?
   • Does the Web IDE Terminal make economic sense for our users?
   • This is largely driven by CI cost. It'd be nice if we could measure this...
6. Usability.
   • Only one terminal per user can be running at a time.
   • A terminal is alive for only 30 minutes before it dies. This information isn't visible to the user at all.
   • All environment features (e.g. "Live Preview") are coupled to the Web IDE Terminal. The user must start the terminal before linting, previewing, and other helpful editor are successful.
7. Reliability.
   • There is no information on the state of the containers being returned, this can lead to conditions where some containers are online in the wrong order.
   • In fact, our docs currently recommend a sleep hack to work around this.

Proposal

TBD