Service discovery of APIs running in tooling containers of Workspace.Next

[garagatyi]

Placeholder for eclipse-che/che#9913

[garagatyi]

In comment I described why issue 10404 may interfere with this one and even make this issue not needed if we agreed to apply the solution suggested in 10404.

@ibuziuk @l0rd since this issue is in the current sprint should we work on it or wait till the discussion in issue 10404 clarifies it?

[garagatyi]

Additional context for the understanding of what is needed to be done in this issues:

Oleksandr Garagatyi:
@ Mario Loriedo @ Ilya Buziuk I recalled what was the reason that I thought that "Service discovery in workspace.next" might not be very easy task even on k8s infra - because we do not create services from WS.NEXT ChePluginEndpoints directly, we create servers and when they get turn into services those services names are generated.
So endpoint with name theia turns into a k8s service with name server26fwgyhm-wsnextdemo-tooling7z1mzzig.
@ Mario Loriedo should we work on that before continuing changing WS.NEXT model objects?

Ilya Buziuk:
@ Oleksandr Garagatyi am I correct that the issue is about not using genearted service names but rather define it somehow on a feature level ?

Oleksandr Garagatyi:
We have endpoints on a ChePlugin level, so we don't need to add anything into the model. But we need to refactor the code in a way that would convert those endpoints into Services and also somehow use Servers to populate path, protocol, etc. (We might use attributes of Services I suppose). But I don't know what exactly we need to do, whether there are any technical issues with that and how hard it would be.