Workspace is considered as STOPPED if start interruption is not implemented

[sleshchenko]

Description

Workspace SPI is designed to allow InternalRuntime doesn't support start interruption.
In this case, it should be possible to stop only RUNNING workspaces.

But if start interruption is not supported by Infrastructure then the following scenario happens:
Initial state: Workspace status is STARTING, runtime start is in progress.

1. A user makes a request to stop a workspace.
2. WorkspaceRuntimes checks that status is starting, sets workspace status to STOPPING, and submit stopping stop task in another thread.
3. A user receives 204 response code.
4. InternalRuntime throws an exception because it is STARTING and doesn't support start interruption.
5. WorkspaceRuntimes sets workspace status to STOPPED and remove InternalRuntime from memory storage.

As result, a runtime is still STARTING (and runtime related operation is performing like image pulling, containers starting, etc.). At the same time, the workspace is considered as STOPPED by Workspace API, and it is allowed to start workspace again.

Reproduction Steps

OS and version:

Diagnostics:

[artaleks9]

Still actual for ver.6.5.0

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