Provide a way to switch to alternate implementations of the che-workspace-client in Che-Theia

[davidfestal]

Is your task related to a problem? Please describe.

Currently, in order to retrieve information about the current workspace, as well as about user preferencesfor example, Che-Theia itself, as well as plugins using the Che-Theia features, use the che-workspace-client REST API client to access the Che server.

In the context of the DevWorkspace Controller, there are use-cases where a central Che Server would not be available nor necessary, but still a substantial part of the data retrieved through this endpoint could be retrieved directly by just reading Kubernetes custom resources (since in this case the workspace is defined as a Custom resource), or by some other way.

Describe the solution you'd like

It would be great, on the Che-Theia side, to allow switching the implementation of the Che workspace client, in order to replace it by a local implementation that, for example, directly reads Kubernetes objects.

Describe alternatives you've considered

Initially, in the Workspace CRD controller, we used to run an additional container in the Workspace POD (called che-rest-apis), that provided a quarkus-based REST server with a minimal implementation of the che-workspace-client API, especially to return the Workspace config and Workspace Devfile provided by the controller, without the need to contact a central Che server.

It would be even better if there was no need to install an additional container, just to serve an alternate implementation of the che-workspace-client API.

Additional context

[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.

[benoitf]

implemented: two bindings in che-theia
che-server and k8s/devworkspace