spec: Clarify what CreateVolume empty volume is

The spec was silent on whether a just-created volume can read back
garbage data left over in the storage from a previous use.  There are
likely applications that depend on a block volume reading as all
zeroes.  Empty filesystems are more likely to do what is desired (as
mkfs is the most likely step to have happened during the creation), at
which point the filesystem will not allow access to any uninitialized
part of the underlying storage.  But putting in an explicit statement
that an empty block volume MUST read as zero is good for security
reasons (one tenant cannot read the leftover garbage leftover by a
previous tenant), even if it the Plugin has to take longer to actually
ensure that scenario.  More likely, Plugins can exploit hardware with
efficient zeroing operations (for example, this is an extension in the
SCSI spec but commonly available) or other techniques (any storage
based by a filesystem has POSIX guarantees that the file started out
reading as all zero; LVM technology has modes where it can guarantee
that all allocations to a dynamcally sized LV starts life reading all
zero).

Even if we later add an optional mode to favor faster creation of
block volumes without explicit zeroing, it should be a non-default
opt-in setup (and only used by a CO that knows the block volume being
allocated will only be used by software that doesn't read the
uninitialized portions of the disk, such as when passing that block to
mkfs).

Signed-off-by: Eric Blake <eblake@redhat.com>

Author: ebblake

spec.md

@@ -789,7 +789,7 @@ Plugins MAY create 3 types of volumes:
 - From an existing volume. When plugin supports cloning, and reports the OPTIONAL capabilities `CREATE_DELETE_VOLUME` and `CLONE_VOLUME`.
 
 If CO requests a volume to be created from existing snapshot or volume and the requested size of the volume is larger than the original snapshotted (or cloned volume), the Plugin can either refuse such a call with `OUT_OF_RANGE` error or MUST provide a volume that, when presented to a workload by `NodePublish` call, has both the requested (larger) size and contains data from the snapshot (or original volume).
-Explicitly, it's the responsibility of the Plugin to resize the filesystem of the newly created volume at (or before) the `NodePublish` call, if the volume has `VolumeCapability` access type `MountVolume` and the filesystem resize is required in order to provision the requested capacity.
+Explicitly, it's the responsibility of the Plugin to resize the filesystem of the newly created volume at (or before) the `NodePublish` call, if the volume has `VolumeCapability` access type `MountVolume` and the filesystem resize is required in order to provision the requested capacity.  Likewise, if an empty volume is created, the Plugin must ensure that an access type `BlockVolume` exposes all bytes to initially read as zero, while an access type `MountVolume` exposes a filesystem with no files pre-populated.
 
 ```protobuf
 message CreateVolumeRequest {