Speed up JavaNIODiskDriver.mapPath()

[buttercookie42]

While trying to speed up file system accesses in directories containing a four-digit amount of files, I've noticed that (at least with SMB1) Windows Explorer seems to issue up to 5 or 6 FIND_FIRST2 requests for launching a file, each of which needs to map the path.

In large directories, this seems to incur a noticeable overhead because in the current implementation, lastDir.list() is unconditionally always called for mapping the filename portion of the path (for the directory portion of the path at least this only happens when we need to fall back to an explicitly case-insensitive search). (I guess SMB2 traffic isn't much affected by this, because there Windows seems to repeatedly open and close the file instead, and the openFile method has a shortcut to not map the path if Files.exists() returns true.)

To fix this, I propose that
a) mapping the file name should take the "if the file exists, simply declare success" approach, too (a number of callers of mapPath already do that as well, too) and only fall back to manually traversing the whole directory for the fallback case-insensitive search, and
b) to rewrite the case-insensitive search to a NIO API-based approach, so we don't always have to preemptively traverse the whole directory, but instead only as far as until we (hopefully) find a match.

With the above fixed, I've found another follow-up issue: A wildcard search issued for listing a directory's whole contents always ends up in mapPath with the * as the "filename". So even with the above fixes in place, we always end up futilely searching the whole directory for the non-existant "*" file. Adding a shortcut for that case speeds up directory listings a bit, too.

With all these changes in place (including the search optimisation from #25), a jfileserver implementation running on my phone is now twice as fast at recursively listing my complete SD card compared to natively running Samba via Termux, even with jfileserver only using SMB1 and Samba using SMB2.

[buttercookie42]

Another performance optimisation that can be made is when the underlying file system is known to be case-insensitive, such as when running on a Windows host, or Android for the public-facing parts of the internal storage (as well as removable SD cards usually). In that case, a non-existing file really is non-existing and part of checking for a similarly-named file with a difference in casing can be skipped.

At least when running on an Android host, for directories with a few thousand files this makes a noticeable difference in performance when creating respectively deleting files, both of which cases try to map non-existing file names either before file creation respectively after file deletion.