[CXF-9227] Fix SecurityManager permission regressions introduced in 4…

[ffang]

….1.7

Summary

Fixes three SecurityManager permission regressions introduced in CXF 4.1.7
that break deployments running under a tight SecurityManager policy (reported
by the WildFly team during their 4.1.6 → 4.1.7 upgrade CI checks).

Root Cause

Issue 1 — NetPermission("getProxySelector") (introduced by #3154)

ProxyFactory.getSystemProxy() calls ProxySelector.getDefault() without
doPrivileged, forcing all callers including user deployments to hold this
permission.

Issues 2 & 3 — RuntimePermission("org.apache.cxf.permission") and
SocketPermission (introduced by #3157)

Setting ACCESS_EXTERNAL_SCHEMA="" on SchemaFactory routes all schema
resolution through SchemaLSResourceResolver → ExtendedURIResolver →
URIResolver.tryFileSystem() — a code path never previously reached in this
context under a SecurityManager. This exposed two pre-existing gaps:

• SecurityActions.fileExists() called sm.checkPermission() outside
  doPrivileged, walking the full call stack into user deployment code.
• URIResolver.createInputStream() called url.openConnection() without
  doPrivileged, requiring callers to hold SocketPermission.

Fix

File	Change
ProxyFactory.java	Wrap ProxySelector.getDefault() in doPrivileged
SecurityActions.java	Move sm.checkPermission() inside the doPrivileged block so the stack walk stops at the CXF privilege boundary (confused-deputy guard preserved)
URIResolver.java	Wrap url.openConnection() in doPrivileged

[ffang]

Thanks @reta !