Huge performance problem deserializing java.nio.file.Path with existing Windows Samba/CIFS mounts

[Gaibhne]

Describe the bug
Deserializing a Path element uses File.listRoots(), which is very costly when the current user has any network mounts.

This bug is amplified by a large factor when the current user has failing network mounts (the cost of simply deserializing a Path object with a failing network mount is an insane ~10 seconds per failing mount), but I would expect (without having the setup to measure it) that there is still a considerable cost due to how NioPathDeserializer is set up.

Note that this happens when deserializing any Path elements, they don't need to be on the/a network share. Even deserializing 'C:' will suffer this bug.

Version information
Noticed it in 2.11.1, still present in latest as of reporting, 2.12.3.

To Reproduce
Due to the nature of this bug, it is only reproducible on a Windows system, and only when the user has network mounts - I'm not sure how one would go about adding one that later fails without a second system in the network to use.

1. Code sample:

TestCase.java:

public class TestCase {
    public Path error;
}

Random App class:

public class App {
    public static void main(String[] args) {
        ObjectMapper mapper = new ObjectMapper(new YAMLFactor());
        TestCase test = mapper.readValue("erro: c:\\", TestCase.class);
    }
}

2. Short snippet is enough to demonstrate the problem
3. A Windows network mount needs to be set up, ideally a failing one (as in one where the mapped resource is unavailable)

Expected behavior
Code execution should be near instant.

Additional context
The problem exists in the JDK itself (tested up to 16), NioPathDeserializer line 30 (in my version; the line in question is for (File file : File.listRoots()) {) triggers the problem. I'm not sure the call is needed at that point, if I am reading the code correctly, in the case of attempting to resolve something like C: on a Windows system will always work, and on a non-Windows system will always result in an error, even without the check and special conditional branch for areWindowsFilePathsSupported.