If a worspace failed to start due to the fact that user stopped it explicitly we should not count it as a failure from the metrics perspective

[ibuziuk]

Describe the bug

Che version

• 7.20.0

Steps to reproduce

• Start a workspace
• While workspace is in the "STARTING" state go to UD and stop it explicitly
• See the error message - 'Failed
  Runtime start for identity 'workspace: xxx, environment: default, ownerId id' is interrupted'
• in the logs there will be smth. like

{"@timestamp":"2020-10-21T13:24:29.677+00:00","@version":1,"message":"Failed to start Kubernetes runtime of workspace workspaceuuuxkjuse6hvvme8.","logger_name":"org.eclipse.che.workspace.infrastructure.kubernetes.KubernetesInternalRuntime","thread_name":"WorkspaceSharedPool-28","level":"WARN","level_value":30000,"stack_trace":"org.eclipse.che.api.workspace.server.spi.RuntimeStartInterruptedException: Runtime start for identity 'workspace: xxx, environment: default, ownerId: id' is interrupted}

• ERROR: Prometheus failure count has been incremented

Expected behavior

• Prometheus failure count should not be incremented since the failure is user driven and expected

Runtime

• kubernetes (include output of kubectl version)
• Openshift (include output of oc version)
• minikube (include output of minikube version and kubectl version)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify)

Eclipse Che Logs

{"@timestamp":"2020-10-21T13:24:29.677+00:00","@version":1,"message":"Failed to start Kubernetes runtime of workspace workspaceuuuxkjuse6hvvme8.","logger_name":"org.eclipse.che.workspace.infrastructure.kubernetes.KubernetesInternalRuntime","thread_name":"WorkspaceSharedPool-28","level":"WARN","level_value":30000,"stack_trace":"org.eclipse.che.api.workspace.server.spi.RuntimeStartInterruptedException: Runtime start for identity 'workspace: xxx, environment: default, ownerId: id' is interrupted}