Calling .metadata() just for .is_{file,dir,symlink} when DirEntry is available

What it does

At Meta internally I've been working on performance optimisations for a number of our widely deployed Rust daemons. One pattern I have repeatedly seen and optimised is:

    for entry in read_dir(".")? {
        entry?.metadata()?.is_dir();
    }

This requires an additional statx() (or equivalent) syscall. In some cases I have saved very large amounts of CPU and IO by just changing to:

    for entry in read_dir(".")? {
        entry?.file_type()?.is_dir();
    }

...which just uses the DT_* returned from readdir().

I plan to implement a lint which detects cases like this (where metadata() is called on entry only to call .is_{file,dir,symlink}().

Does this sound reasonable?

Advantage

• Reduced CPU instructions
• Reduced IO cost

Drawbacks

No response

Example

See above description.

No files or tests are named. Start by reviewing the two read_dir examples and the existing Clippy lint structure, then identify how equivalent filesystem-method lints are registered and tested. Done means the lint detects metadata() used only for is_file, is_dir, or is_symlink and guides users toward file_type().