btrfs/300: set umask to avoid failure on systems with a different umask

btrfs/300: set umask to avoid failure on systems with a different umask

The test is assuming a umask of 0022, which is the default on many Linux
setups, but often we can find other umasks such as in recent Debian box
I have where the default umask is 0002, and this makes the test fail like
this:

  $ ./check btrfs/300
  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian7 6.16.0-rc1-btrfs-next-200+ #1 SMP PREEMPT_DYNAMIC Thu Jun 12 16:07:55 WEST 2025
  MKFS_OPTIONS  -- /dev/sdb
  MOUNT_OPTIONS -- /dev/sdb /scratch

  btrfs/300 2s ... - output mismatch (see /xfstests/results//btrfs/300.out.bad)
    --- tests/btrfs/300.out	2024-05-20 11:27:55.949395116 +0100
    +++ /xfstests/results//btrfs/300.out.bad	2025-06-12 22:58:20.449228230 +0100
    @@ -2,16 +2,16 @@
     Create subvolume './subvol'
     Create subvolume 'subvol/subsubvol'
     drwxr-xr-x fsgqa fsgqa ./
    -drwxr-xr-x fsgqa fsgqa ./subvol
    --rw-r--r-- fsgqa fsgqa ./subvol/1
    --rw-r--r-- fsgqa fsgqa ./subvol/2
    --rw-r--r-- fsgqa fsgqa ./subvol/3
    ...
    (Run 'diff -u /xfstests/tests/btrfs/300.out /xfstests/results//btrfs/300.out.bad'  to see the entire diff)

  HINT: You _MAY_ be missing kernel fix:
        94628ad94408 btrfs: copy dir permission and time when creating a stub subvolume

  Ran: btrfs/300
  Failures: btrfs/300
  Failed 1 of 1 tests

  $ diff -u /xfstests/tests/btrfs/300.out /xfstests/results//btrfs/300.out.bad
  --- /xfstests/tests/btrfs/300.out	2024-05-20 11:27:55.949395116 +0100
  +++ /xfstests/results//btrfs/300.out.bad	2025-06-12 22:58:20.449228230 +0100
  @@ -2,16 +2,16 @@
   Create subvolume './subvol'
   Create subvolume 'subvol/subsubvol'
   drwxr-xr-x fsgqa fsgqa ./
  -drwxr-xr-x fsgqa fsgqa ./subvol
  --rw-r--r-- fsgqa fsgqa ./subvol/1
  --rw-r--r-- fsgqa fsgqa ./subvol/2
  --rw-r--r-- fsgqa fsgqa ./subvol/3
  -drwxr-xr-x fsgqa fsgqa ./subvol/subsubvol
  --rw-r--r-- fsgqa fsgqa ./subvol/subsubvol/4
  --rw-r--r-- fsgqa fsgqa ./subvol/subsubvol/5
  --rw-r--r-- fsgqa fsgqa ./subvol/subsubvol/6
  -drwxr-xr-x fsgqa fsgqa ./snapshot
  --rw-r--r-- fsgqa fsgqa ./snapshot/1
  --rw-r--r-- fsgqa fsgqa ./snapshot/2
  --rw-r--r-- fsgqa fsgqa ./snapshot/3
  +drwxrwxr-x fsgqa fsgqa ./subvol
  +-rw-rw-r-- fsgqa fsgqa ./subvol/1
  +-rw-rw-r-- fsgqa fsgqa ./subvol/2
  +-rw-rw-r-- fsgqa fsgqa ./subvol/3
  +drwxrwxr-x fsgqa fsgqa ./subvol/subsubvol
  +-rw-rw-r-- fsgqa fsgqa ./subvol/subsubvol/4
  +-rw-rw-r-- fsgqa fsgqa ./subvol/subsubvol/5
  +-rw-rw-r-- fsgqa fsgqa ./subvol/subsubvol/6
  +drwxrwxr-x fsgqa fsgqa ./snapshot
  +-rw-rw-r-- fsgqa fsgqa ./snapshot/1
  +-rw-rw-r-- fsgqa fsgqa ./snapshot/2
  +-rw-rw-r-- fsgqa fsgqa ./snapshot/3
   drwxr-xr-x fsgqa fsgqa ./snapshot/subsubvol

The mismatch with the golden output is because the test is expecting an
umask of 0022 where the write bit is not set for owner group, but with
a umask of 0002 for example, the write bit is set for the owner group.

Fix this by making the test set a umask of 0022, so that it works for
any system or user defined umask.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>