Should we make SslOptions be more explicit about where it loads certifications?

I'm not sure I like the default fallback behavior here:

https://github.com/jooby-project/jooby/blob/e9b889d593f630182b0c28db50e24c0d65215d35/jooby/src/main/java/io/jooby/SslOptions.java#L245

Instead I recommend something more like:

     static InputStream getResource(
            String path)
            throws FileNotFoundException, IOException {

        URI uri = URI.create(path);

        /*
         * Explicit
         */
        if ("classpath".equals(uri.getScheme())) {
            var classpath = uri.getPath();
            if (classpath == null) {
                throw new FileNotFoundException(path);
            }
            return getClasspathResource(classpath);
        }
        if ("file".equals(uri.getScheme())) {
            return Files.newInputStream(Path.of(uri));

        }
        /*
         * Implicit
         */
        Path filepath = Paths.get(path);
        if (Files.exists(filepath)) {
            // absolute file:
            return Files.newInputStream(filepath);

        }
        // Maybe do not do this
        return getClasspathResource(path);
    }

This is where classpath:/// and file:/// can be explicitly used and then if that is not used we do the original behavior with the eventual goal of not doing the classpath unless it has the classpath uri schema.

The reason is assume I package a certification in the classpath. It works normally. Then someone adds a classpath on the filesystem when I go deploy. It now overrides the classpath one.

Now I admit this is unlikely and if this was not certs I could care less but I think we should not go around sniffing for certs. It also seems more inline with how we no longer use the service loader. That is less implicit behavior.

Otherwise I mostly don't care but just think this is the right thing to do.

先阅读第 245 行附近的 SslOptions.java，跟踪当前如何解析证书路径。将 issue 中明确的 classpath 和 file URI 情况与现有的 fallback 行为进行比较，然后确认预期的兼容性规则，并为已达成一致的解析路径添加覆盖。