--is-reflink and rm_util_link_type fixes

[cebtenzzre]

The most important change here is to allow rm_util_link_type to return RM_LINK_SYMLINK by checking for it earlier.

$ touch foo.txt bar.txt
$ ln -s bar.txt link.txt
$ rmlint --is-reflink foo.txt link.txt

Result before these changes: Not a file (exit status 3) Result after these changes: Encountered a symlink (exit status 9)

[SeeSpotRun]

Thanks for contributing, much appreciated. Feel free to add a nosetest.

[SeeSpotRun]

Actually thinking about it, we should also be testing that they are links to each other, ie should expect RM_LINK_NONE for rmlint --is-reflink foo.txt link.txt in your example and RM_LINK_SYMLINK for rmlint --is-reflink bar.txt link.txt

[cebtenzzre]

Working on a nosetest. I considered testing for a symlink relationship, but rm_util_link_type is primarily for detecting reflinked files. For functions like rm_sh_emit_handler_clone, knowing that two files are hardlinked or that either is a symlink is enough to know that they aren't reflinked. And what would the link type be for a symlink to a path double, hardlink, or reflink?

A script can use realpath to resolve symlinks, then use the result of rmlint --is-reflink to identify the relationship between the destinations. IMO, the most straightforward enhancement would be to add a -L flag to preprocess both arguments with realpath(3) - in that mode, "symlink" would not be a possible status, only "same (resolved) path".