Fix returning d_type by readdir(3) in off == 0 mode

[jpandre]

When using the off == 0 mode and not using the readdir_plus mode,
the d_type was not returned, and the use_ino flag was not used for
returning d_ino.

Until a recent patch, this was also the case when using the readdir_plus
mode. It is likely the original developer intentionally used the
offs == 0 situation to trigger something while processing the first
call.

So this patch fixes the returned values for d_ino and d_type in both
with and without the readdir_plus mode. It also restores the original
design for the first returned entry in readdir_plus mode.

The test for the returned d_ino when off == 0 has been adjusted to
take the d_type into consideration.

[Nikratio]

Not sure I understand this change. Why do we want to throw away most of the statp information when seeking is not supported?

[jpandre]

Oh, I did not want to deprive any project of the stat information when available. This intent was not mentioned in the rationale which led to removing the "off == 0" check.

Rather, I think this check was there for a reason (possibly because some file system needed it), and I just wanted to avoid a possible regression.

Now, if the stat information is a useful feature on the first returned entry in readdir_plus mode (usually this is "."), this is a good rationale for removing the check, so let me keep it removed. This has no effect in my use cases.

[Nikratio]

Got you. Yes, I'd rather leave this as-is.

[jpandre]

This proposal keeps the off == 0 test as is and only deals with the non-plus readdir(3). Also the passthrough check has been extended to test readdir(3) in both modes.

The title should be changed consequently (which I probably cannot do).

[Nikratio]

Thanks for working on this!

[nh2]

I can confirm that this PR fixes readdir() always returning DT_UNKNOWN in sshfs, thus making many recursive directory traversal operations in many programming languages much faster, as they don't need to fall back to stat().

Thank you!