The implementation should have preserved an existing ephemeral volume
source during an update even when the feature gate is currently
disabled, but due to a cut-and-paste error it was checking for CSI
volumes instead.

The new test detected that. It's based on
https://github.com/kubernetes/kubernetes/pull/97058/files#diff-7826f7adbc1996a05ab52e3f5f02429e94b68ce6bce0dc534d1be636154fded3

Silently ignoring the unsupported volume type leads to:

  Warning  FailedMount       8s    kubelet            Unable to attach or mount volumes: unmounted volumes=[my-csi-volume default-token-bsnbz], unattached volumes=[my-csi-volume default-token-bsnbz]: failed to get Plugin from volumeSpec for volume "my-csi-volume" err=no volume plugin matched

The new message is easier to understand:
  Warning  FailedMount       6s (x5 over 49s)  kubelet            Unable to attach or mount volumes: unmounted volumes=[my-csi-volume], unattached volumes=[my-csi-volume default-token-rwlpp]: volume my-csi-volume is a generic ephemeral volume, but that feature is disabled in kubelet

This simulates various error scenarios (PVC not created for pod,
feature disabled) and switching between feature disabled and enabled.

Without this error, kube-scheduler was simply ignoring the special
volume source and scheduled the pod. This was unlikely to work in
practice because the volume might have needed binding or the feature
is also disabled on kubelet which then doesn't know what to do with
the volume.

This covers some failure scenarios and feature gate enablement.