Add an ability to list available k8s namespaces

[sleshchenko]

What does this PR do?

It does not change the current workspace creating flow, but used namespace still managed by che.infra.kubernetes.namespace. See more how workspace creation flow will be changed #14376 (comment).

And this PR introduces API that will be used by clients to provide an ability for users to see target namespace info, and choose one if multiple are available.

So, there are two configuration properties that are used for configuring a list of available namespaces:
1.

# Defines Kubernetes default namespace in which user's workspaces are created
# if user does not override it.
# It's possible to use <username> and <userid> placeholders (e.g.: che-workspace-<username>).
# In that case, new namespace will be created for each user.
# Is used by OpenShift infra as well to specify Project
#
# BETA It's not fully supported by infra.
# Use che.infra.kubernetes.namespace to configure workspaces' namespace
che.infra.kubernetes.namespace.default=<username>-che

# Defines if a user is able to specify Kubernetes namespace different from default.
# It's NOT RECOMMENDED to configured true without OAuth configured.
# Is used by OpenShift infra as well to allows users choose Project
#
# BETA It's not fully supported by infra.
# Use che.infra.kubernetes.namespace to configure workspaces' namespace
che.infra.kubernetes.namespace.allow_user_defined=false

Example of the implemented API response:

[
  {
    "name": "my-dev",
    "attributes": {
      "status": "Running"
  },
  {
    "name": "java-ws-dedicated",
    "attributes": {
      "status": "Terminating"
  },
  {
    "name": "sleshche-che-ws",
    "attributes": {
      "default": "true"
      // Note that status is missing - means that such namespace does not exist on Cluster and will be created on the first workspace start
    }
  }
]

What can be improved later

1. User may not have permissions to create objects in some of the available namespaces. So, we could check if they have like deployment creation permissions before returning namespace. But it would require upgrading fabric8 k8s client(See K8s fabric8io/kubernetes-client@d1f2e77), it's why I would like to do it in a separate issue if needed.
2. On K8s infrastructure, OAuth is not implemented yet. Just allowing to choose any available namespace would mean allowing users to access any k8s namespace, even system like kube-system. @metlos propose to introduce a dedicate property to configure selector for available namespaces like che.infra.kubernetes.namespace.user_available_selector=app=che.
3. In most OpenShift production cases - admin would need to precreate users' project and apply needed quotas there. So, the user would not be able to create new projects.
   But on some tests environments like minikube, minishift, crc a user is able to create new namespaces... So, it may be useful (may be not) to implement an ability to type free namespace name value and then Che would create this on the first workspace start.
   It may be implemented in two ways: checks automatically if a user is able to create a new namespace OR let che admin to configure such an ability with a dedicated configuration property.
   API could expose such an ability by returning a special namespace holder, like:

  {
    "name": "{new-namespace}"
  }

Is this PR well-tested?

Not yet. It will be tested and as proof will be here screenshots for different configurations and infrastructures.

Tested configurations

Kubernetes: Single-User

1. Introduced parameters are default:
   che.infra.kubernetes.namespace.default=<username>-che
che.infra.kubernetes.namespace.allow_user_defined=false

Since in single-user mode there is only one che user, default namespace is che-che, which is not good but should not a big issue and may be handled by chectl - like override default namespace for single user to be the same as che namespace, it actully works in such way.
So, che-che namespace does not exist:

[
  {
    "name": "che-che",
    "attributes": {
      "default": "true"
    }
  }
]

2. Introduced parameters are default:
   che.infra.kubernetes.namespace.default=che
che.infra.kubernetes.namespace.allow_user_defined=false

[
  {
    "name": "che",
    "attributes": {
      "phase": "Active",
      "default": "true"
    }
  }
]

3. Introduced parameters are default:
   che.infra.kubernetes.namespace.default=NULL
che.infra.kubernetes.namespace.allow_user_defined=true

[
  {
    "name": "che",
    "attributes": {
      "phase": "Active"
    }
  },
  {
    "name": "default",
    "attributes": {
      "phase": "Active"
    }
  },
  {
    "name": "kube-node-lease",
    "attributes": {
      "phase": "Active"
    }
  },
  {
    "name": "kube-public",
    "attributes": {
      "phase": "Active"
    }
  },
  {
    "name": "kube-system",
    "attributes": {
      "phase": "Active"
    }
  }
]

OpenShift - Multiuser

1. OAuth is configured and introduced parameters are default: che.infra.kubernetes.namespace.default=<username>-che
che.infra.kubernetes.namespace.allow_user_defined=false

Logged in as developer, developer-che exists:

[
  {
    "name": "developer-che",
    "attributes": {
      "description": "A project to run Che Workspaces",
      "displayName": "Che Workspaces",
      "default": "true",
      "description": "A project to run Che Workspaces"
    }
  }
]

2. OAuth is configured and introduced parameters are:
   che.infra.kubernetes.namespace.default=<username>-che
che.infra.kubernetes.namespace.allow_user_defined=true

Logged in as developer, the user has developer-che and myproject projects:

[
  {
    "name": "developer-che",
    "attributes": {
      "phase": "Active",
      "description": "A project to run Che Workspaces",
      "default": "true",
      "displayName": "Che Workspaces"
    }
  },
  {
    "name": "myproject",
    "attributes": {
      "phase": "Active",
      "description": "Initial developer project",
      "displayName": "My Project"
    }
  }
]

3. OAuth is configured and introduced parameters are:
   che.infra.kubernetes.namespace.default=<username>-che
che.infra.kubernetes.namespace.allow_user_defined=true

Logged in as developer, the user has myproject project only:

[
  {
    "name": "developer-che",
    "attributes": {
      "default": "true"
    }
  },
  {
    "name": "myproject",
    "attributes": {
      "phase": "Active",
      "description": "Initial developer project",
      "displayName": "My Project"
    }
  }
]

4. OAuth is configured and introduced parameters are:
   che.infra.kubernetes.namespace.default=NULL
che.infra.kubernetes.namespace.allow_user_defined=true

Logged in as developer, the user has myproject project only:

[
  {
    "name": "myproject",
    "attributes": {
      "phase": "Active",
      "description": "Initial developer project",
      "displayName": "My Project"
    }
  }
]

What issues does this PR fix or reference?

It resolves #14376

Release Notes

N/A

Docs PR

N/A
The workflow that user/admin would use is not complete yet, documentation will be provided in further PRs where workflow will be available.

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• "che-server" docker image: maxura/che-server:14541

[che-bot]

E2E tests of Eclipse Che Multiuser on OCP has failed:

• Build details
• Test report
• docker image: eclipseche/che-server:14541
  https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.
  Use command "ci-test" to rerun the test.

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• "che-server" docker image: maxura/che-server:14541

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• "che-server" docker image: maxura/che-server:14541

[sleshchenko]

cc @amisevsk @metlos Could you do final round of review.

[che-bot]

E2E tests of Eclipse Che Multiuser on OCP has been successful:

• Build details
• Test report
• docker image: eclipseche/che-server:14541

[amisevsk]

Great work, just a few more minor comments.

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has failed:

• build details
• "che-server" docker image: maxura/che-server:14541
• test artifacts
• https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.
  Use command "crw-ci-test" to rerun the test.

[che-bot]

E2E tests of Eclipse Che Multiuser on OCP has been successful:

• Build details
• Test report
• docker image: eclipseche/che-server:14541

[amisevsk]

LGTM, well done.

[sleshchenko]

crw-ci-test

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• logs and configs
• "che-server" docker image: maxura/che-server:14541

[che-bot]

E2E tests of Eclipse Che Multiuser on OCP has been successful:

• Build details
• Test report
• docker image: eclipseche/che-server:14541

[metlos]

I've approved this. The only comment I have is to ever so slightly increase the test coverage, but I don't think that blocks merging this.

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• logs and configs
• "che-server" docker image: maxura/che-server:14541

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has been successful:

• build details
• logs and configs
• "che-server" docker image: maxura/che-server:14541

[che-bot]

E2E tests of Eclipse Che Multiuser on OCP has been successful:

• Build details
• Test report
• docker image: eclipseche/che-server:14541