btrfs: test qgroup deletion races with squota writes

btrfs: test qgroup deletion races with squota writes

When using simple quotas, an extent's EXTENT_OWNER_REF can long outlive
the subvolume that created it, since the extent can pick up additional
references that keep it alive after the owning subvolume is deleted.

Several lifecycle bugs around the owning qgroup arise from this:

  1. Freeing an extent whose owner qgroup is gone: must not cause an
     underflow nor a transaction abort.

  2. Creating an extent in the same transaction that the owner subvolume
     is deleted: the qgroup may already be gone by the time the squota
     delta is recorded, leaving behind an EXTENT_OWNER_REF that points
     at a qgroup that never accumulated a usage delta.  Manually
     re-creating that qgroup and then freeing the extent would underflow
     it.

  3. Destroying a live subvolume's qgroup while delayed refs for newly
     allocated tree blocks have not yet flushed: rfer/excl read as 0,
     so the destroy looked safe, but the alloc delta was silently lost.

  4. Destroying the qgroup of a live subvolume whose data predates
     'btrfs quota enable --simple': pre-existing extents are not
     accounted (generation < qgroup_enable_gen), so rfer/excl stay 0
     permanently and a usage-only check happily destroys a qgroup
     belonging to a still-mounted, still-writeable subvolume.

Add four cases covering these scenarios.  On a fixed kernel all four
'qgroup destroy' (and the re-create in case 2) operations are refused
because the subvol check rejects the request; on an unfixed kernel
they would succeed and leave the filesystem with broken accounting or
trigger a transaction abort.

Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Anand Jain <asj@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>