btrfs: stripe_alloc: let the property accept a cache-less filesystem like the mount option does
The "stripe_alloc" filesystem property and the mount option are meant to
be two ways to turn on one policy, and they answer the same questions
about the filesystem -- except one. btrfs_check_mountopts() refuses the
option only for space_cache=v1: the v1 cache inode is nodatacow and
preallocated, so a commit overwrites it in place, a sub-stripe write
into committed stripes that no csum would ever show. The free space
tree and no cache at all are both fine, and nothing in the allocator
reads either. btrfs_stripe_alloc_check_support(), which the property
calls, demanded the free space tree instead, so a filesystem mounted
with nospace_cache took the option but refused the property, and the
error it gave named a requirement the option does not have.
Refuse what the mount path refuses: the v1 cache, both the live option
and cache inodes still on disk from an earlier mount, which
btrfs_read_block_groups() already refuses for the option (the property
can arrive on a live filesystem, after that check ran). The two paths
now agree, and bg-gate-test.sh's property cases hold them to it.