Shouldn't change my kube conf if I delete the current project

[adietish]

Steps:

1. ASSERT: have your own project (not the default one) on your cluster
2. ASSERT: your project is the current project in the kube config (oc project would tell you)
3. EXEC: in vscode: pick "Delete" in it's context menu
4. EXEC: check what current project it is using after it was successfully deleted
5. EXEC: verify the current project in kube config using oc project

Result:
VSCode is now using "default" as current project. The current project in the kube config was changed to "default", too.

Expected result:
vscode shouldn't change the current project in the kube config. It should error instead and maybe allow me to change to a current different project in the error.

This was agreed as the behavior for intellij-openshift-connector in redhat-developer/intellij-openshift-connector#618 (comment)
We ideally should be consistent in intellij and vscode.

[vrubezhny]

@adietish Is his fixed in IntelliJ-OpenShift?
Could you please provide a short video with or a screenshot with the result of project deletion, including possible error messages that may appear on IltelliJ as result?

[vrubezhny]

@adietish After the PR #3804 is merged, the Kube config isn't touched anymore after the project is deleted on a cluster.

Screencast.from.2024-01-16.16-07-00.webm

The deleted project is still shown in App Explorer, but as a "Missing project" with the only action available - Create new or select active project. Contexts isn't get switched after the project deletion, so you can create another project or select an existing one for this context (and Kube config is to be updated in case of different project is selected/created)

The only problem I see (see the screencast) is that when we try to create a new project after we've just deleted the active project within the same context - everything goes well, but the App Explorer project tree doesn't get updated, so we need to update it manually. But this is another issue.

[vrubezhny]

@adietish Do have any objections to close this as fixed with #3804?

[vrubezhny]

Closing as fixed with #3804