generic: test fsync on inode with many hard links

generic: test fsync on inode with many hard links

This test is motivated by an fsync issue discovered in btrfs.
The issue in btrfs was that adding a new hard link to an inode that
already had a large number of hardlinks and fsync the inode, would
make the fsync log replay code update the inode with a wrong link count
(smaller than the correct value). This resulted later in dangling
directory index entries, after removing most of the hard links
(correct_value - wrong_value), that were visible to user space but it
was impossible to delete them or do any other operation on them (since
they pointed to an inode that didn't exist anymore, resulting in -ESTALE
errors).

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

   Btrfs: fix fsync when extend references are added to an inode

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>