Che server technical debt

[skabashnyuk]

Is your enhancement related to a problem? Please describe.

As part of this issue, I would like to summarise existed technical debt for the "Che server".
The current "Che server" architecture has a long history that comes from Che4/Che5. Since that time
it was changed from mainly Docker strimmed technology to mainly K8s based. Quite a few of the internal process
is no longer needed or has no sense at all. Devfile introduction in Che7 was made in a very
short period that doesn't allow us to make a lot of pieces in an efficient manner. For example, during workspace startup, we convert Devfile to WorkspaceConfig and still use Che6 models.
All of that brings some complication which accumulates over time. That means that introduction
of new features such as #17829 can be significantly slower next time.

Workspaces startup process.

As I mention during the workspace startup we convert Devfile to WorkspaceConfig and still use Che6 models.
We would like to revise our workspaces startup process and make it more up to date. However, before we start doing any changes would be reasonable to document(internal tech document) existed process to better understand what is happening and what
we can improve.
Potential improvement after that

• New workspace startup phases. Like devfile resolution from git repository or HTTP server. Che to perform git clone of projects to reduce errors and for easier integration with editors #15973
• etc.

Legacy concepts/code/objects/methods

• We uses WorkspaceConfig(che6) internally during workspace startup
• We still have notion of Installers(che6)
• We still have notion of Agents(che6)
• Legacy k8s namespace strategy introduce additional complexity

General source code maintenance

• Replace wsmaster by eradicating problematic language Replace wsmaster by eradicating problematic language #17602
• During the transition to che 7 we get rid of many dependencies that were used by the workspace agent. Some
  of dependencies are still declared in the parent pom.

Single user vs multi-user

TBD

Single host vs multi-host

TBD

Describe the solution you'd like

action items

• High-level development documentation/diagram about internal steps/processes that are happening during workspace startup
• Documentation about the differences of single/multi-user
• Admin guide about different strategies that are used to handle k8s namespaces for the Che workspaces.
• Legacy namespace strategies - study what we can improve/simplify in this area Remove the code that support namespace strategies other than "per user" #19536
• Remove the notion of installers in source code Remove installers entity  #18130
• Remove the notion of agents in source code https://github.com/eclipse/che/blob/master/wsmaster/che-core-api-workspace/src/main/java/org/eclipse/che/api/workspace/server/hc/probe/WorkspaceProbesFactory.java#L53
• Switch git master branch to main
• Rename master maven modules to 'che-server'
• Rename github issue label wsmaster to che-server
• Environment.context
• Get rid of unused maven dependencies that is declared in the parent pom
• Get rid of unused properties in che.properties in multiuser.properties Some properties are only present in che.properties #14946 Remove unused values from che.properties and related code #18202
• Remove docker infrastructure alternatives. https://github.com/eclipse/che/blob/8305c38bc5899e62761148d3628bebc5149eb1de/assembly/assembly-wsmaster-war/src/main/java/org/eclipse/che/api/deploy/WsMasterModule.java#L332-L333

Describe alternatives you've considered

n/a

Additional context

n/a

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.