generic: test fsync on inode with many hard links differently

This test is motivated by an fsync issue discovered in btrfs.
The steps to trigger the issue were:

1) remove an hard link from an inode with a large number of hard links;
2) add a new hard link;
3) add another hard link with the same name as the one removed in step 1;
4) fsync the inode.

These steps made the btrfs fsync log replay fail (with the -EOVERFLOW
error), making the filesystem unmountable, requiring the use of
btrfs-zero-log (it wipes the fsync log) in order to make the filesystem
mountable again (but losing some data/metadata).

The btrfs issue was fixed by the following linux kernel patches:

  Btrfs: fix fsync when extend references are added to an inode
  Btrfs: fix fsync log replay for inodes with a mix of regular refs and extrefs

This issue was present in btrfs since the extrefs (extend references)
feature was added (2012).

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

tests/generic/041.out

@@ -0,0 +1,3 @@
+QA output created by 041
+Link count: 3003
+hello world