Add automount subpaths option

[amisevsk]

What does this PR do?

Add subpath option to the controller.devfile.io/mount-as annotation, enabling configmaps/secrets to be mounted as subpath volumemounts in the devworkspace.

This change also makes it so that the DevWorkspace Operator does not create the devworkspace-gitconfig map when it would be empty, as this interfered with what I was trying to test (mounting my gitconfig into workspaces)

What issues does this PR fix or reference?

The main use-case here is mounting files from a configmap/secret to an already-populated directory in the container. The benefit of using "subpath" is that files can be mounted into existing directories, with the downside that changes on the cluster side are not propagated into running workspaces.

Is it tested? How?

E.g. provisioning your local ~/.gitconfig into all DevWorkspaces in a namespace:

1. Create configmap with gitconfig contents:

   kubectl create configmap git-config \
     --from-file=gitconfig=${HOME}/.gitconfig
   
   kubectl patch cm git-config --type merge -p '
   metadata:
     labels:
       controller.devfile.io/mount-to-devworkspace: "true"
       controller.devfile.io/watch-configmap: "true"
     annotations:
       controller.devfile.io/mount-path: "/etc/"
       controller.devfile.io/mount-as: "subpath"
   '

2. Start a DevWorkspace
3. Exec into the workspace and execute git config --list --show-origin

PR Checklist

• E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • v8-che-happy-path: Happy path for verification integration with Che

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk, JPinkney

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JPinkney,amisevsk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[JPinkney]

/test v8-devworkspace-operator-e2e

[l0rd]

What's controller.devfile.io/watch-configmap: "true" for?

[amisevsk]

What's controller.devfile.io/watch-configmap: "true" for?

It's a required label to enable the configmap to be cached by the Operator. In #652 we limited the controller's objects cache based on labels in order to reduce memory usage (on large clusters, not doing this means caching e.g. every secret/configmap in-memory in the controller).

For configmaps and secrets, there's no single label that's used for all use-cases, so we had to add explicit labels watch-configmap and watch-secret to enable the DevWorkspace Operator to track them. Without these labels, secrets and configmaps are invisible to the DevWorkspace Operator.