Improve naming for wsnext tooling containers

[benoitf]

Description

When using ws.next workspaces, containers coming from plugins are named in my case:

• toolingqtm22ewy
• toolingtv4icpyu

it would be nice if the name could contain more details like the name of the plugin

it would help for example when you need to go to a terminal

[sleshchenko]

@benoitf There is another issue to use sidecar container name (but not plugin name) as container name #11096. If you are OK with such containers naming please close the issue as duplicate.

[sleshchenko]

So, the scope of this issue is to implement using container name from sidecar definition instead of generating one. Note that collision issue should not be covered here and there may be cases when two plugins provide the same containers with the same name and it will lead to workspace start failure.

[benoitf]

plugin's id as prefix/suffix shouldn't make it collide (could be a way to solve collision)

[sleshchenko]

plugin's id as prefix/suffix shouldn't make it collide (could be a way to solve collision)

@garagatyi WDYT?

[garagatyi]

The problem would be the signs used in the ID - k8s is very restrictive in that.
Previously, I implemented random names and @l0rd suggested moving to the names from the sidecar definition, so would be nice to hear his opinion on that. But since this name is needed to just identify where the container is belong I'm ok with such an approach.
Since @AndrienkoAleksandr is working on matching containers on k8s infra for the exec/terminal plugins it make sense to involve him as well

[sleshchenko]

@l0rd Could you please confirm that you are OK with naming containers in workspaces as {PLUGIN_NAME} + - + {CONTAINER_NAME}?
But then we have to limit possible characters for plugins and their containers names
I think here is describe naming convention https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, -, and .

[sleshchenko]

I believe it should be fixed by #11465