Workspaces that define Kubernetes/OpenShift components with URIs always fail to start

[amisevsk]

Description

If a DevWorkspace includes a Kubernetes or OpenShift-type component that uses the uri field, that workspace will fail to start, even if the component has deployByDefault: false.

For components with deployByDefault: false, starting the workspace should not be a problem, as the component is expected to be applied to the cluster at some later point (by e.g. running an apply command).

For components with deployByDefault: true, we should still start the workspace, instead ignoring those components and adding a warning to the workspace.

How To Reproduce

Apply the DevWorkspace

apiVersion: workspace.devfile.io/v1alpha2
kind: DevWorkspace
metadata:
  name: plain
spec:
  routingClass: basic
  started: true
  template:
    attributes:
      controller.devfile.io/storage-type: ephemeral
    components:
    - name: web-terminal
      container:
        command: ["tail", "-f", "/dev/null"]
        image: quay.io/amisevsk/web-terminal-tooling:dev
        memoryLimit: 512Mi
        mountSources: true
    - name: test-k8s
      kubernetes: 
        deployByDefault: false
        uri: https://raw.githubusercontent.com/devfile/devworkspace-operator/main/deploy/deployment/kubernetes/objects/devworkspace-controller-metrics.Service.yaml

Expected behavior

If a workspace uses a kubernetes component with deployByDefault: false, we shouldn't care if DWO supports URIs or not

If a workspace instead has deployByDefault: true, it would still be useful to start the workspace, downgrading the failure (and webhook rejection) to a warning.

Additional context

[amisevsk]

cc: @l0rd we discussed this on Wednesday as an issue with https://registry.devfile.io/ compatibility.