generic/050: add a workaround for btrfs

generic/050: add a workaround for btrfs

[BUG]
With the incoming btrfs shutdown ioctl/remove_bdev callback support,
btrfs can be tested with the shutdown group.

But test case generic/050 still fails on btrfs with shutdown support:

generic/050 1s ... - output mismatch (see /home/adam/xfstests/results//generic/050.out.bad)
    --- tests/generic/050.out	2022-05-11 11:25:30.763333331 +0930
    +++ /home/adam/xfstests/results//generic/050.out.bad	2025-06-30 10:22:21.752068622 +0930
    @@ -13,9 +13,7 @@
     setting device read-only
     mounting filesystem that needs recovery on a read-only device:
     mount: device write-protected, mounting read-only
    -mount: cannot mount device read-only
     unmounting read-only filesystem
    -umount: SCRATCH_DEV: not mounted
     mounting filesystem with -o norecovery on a read-only device:
    ...
    (Run 'diff -u /home/adam/xfstests/tests/generic/050.out /home/adam/xfstests/results//generic/050.out.bad'  to see the entire diff)
Ran: generic/050

[CAUSE]
The test case generic/050 has several different golden output depending
on the fs features.

For fses which requires data write (e.g. replay the journal) during
mount, mounting a read-only block device should fail.
And that is the default golden output.

However for btrfs, although it has something similar to a journal, aka
log tree, it's not the traditional journal which is used to protect
metadata update.

The log tree of btrfs is mostly for speeding up fsync() without syncing
the full fs.

This means several things are different with btrfs:

- Regular metadata update won't cause dirty log tree
  The workload here is just touching several files, which will not cause
  the creation of btrfs log tree.

  And the metadata consistency is protected by metadata COW, not
  journal.

- FLUSHLOG shutdown flag will cause btrfs to commit the current
  transaction
  And above new files are recorded in the current transaction, meaning
  those new files will be fully written by a FLUSHLOG shutdown.

This means, unlike fses using traditional journals, touching files then
shutdown with FLUSHLOG will not cause any dirty log tree.

This makes btrfs acts like it doesn't support metadata journaling, at
least for this particular test case.

[FIX]
Since the workload here will not cause btrfs to generate a log tree,
meaning after the shutdown, the fs can still be mounted RO even the
block device is read-only.

So here we have to make an exception for btrfs, that it has to go
through the "nojournal" feature.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>