wait_for_ready on cozystack_vmdisk returns before the disk is populated #59

Once cozystack/cozystack#4380 lands, wait_for_ready on a cozystack_vmdisk returns while CDI is still populating the disk, and the ready attribute reads true for a disk that holds no data yet.

The cause is the meaning of Ready on the platform side. With #4380 the vm-disk ApplicationDefinition exempts the DataVolume from the Helm wait, so a VMDisk's Ready follows the Helm release and turns True as soon as the manifests are applied. Whether the import or clone finished is reported in a separate condition, WorkloadsReady, which the WorkloadMonitor keeps False while the DataVolume is in flight, Failed or has no phase. The reason for moving it off Ready is cozystack/cozystack#4145: a Helm wait on an importing disk holds a helm-controller worker for the whole install timeout.

The provider only reads Ready. WaitForReady in internal/client/application.go polls app.Status.Ready, and readyFromConditions matches type == "Ready" and nothing else (at 55ba580). A plan that creates a disk and then a VM that boots from it can therefore start the VM against an empty or failing disk.

The provider could also wait on WorkloadsReady, when the object carries that condition. Applications without a WorkloadMonitor have no such condition, so its absence should not block. Doing it for every kind, not just vmdisk, is probably right, since WorkloadsReady is where the platform reports that the workloads behind a release came up.