Adopt Apache Commons Secure XML for XML parsing

[snoopdave]

Summary

Roller configured its XML parsers by hand in two places, with two separate feature lists:

• SafeSAXBuilder, used for JDOM parsing (bookmark import, theme metadata, runtime config definitions, menus).
• WebloggerImpl, which set features on the XML-RPC library's shared SAXParserFactory. If the parser did not accept a setting, it logged an error and continued.

This PR moves both onto Apache Commons Secure XML 1.0.0:

• New SecureXmlParsers returns a namespace-aware, non-validating SAXParserFactory from SecureSAXParserFactory.newNSInstance(), and refuses document type declarations on top, as Roller did before. It throws if the configuration cannot be applied.
• SafeSAXBuilder now gets its readers from SecureXmlParsers. It keeps its existing settings as an overlapping layer, so all its call sites are unchanged.
• WebloggerImpl installs the same factory for XML-RPC with SAXParsers.setSAXParserFactory(...). Startup now fails instead of continuing with an unconfigured parser.

The new dependency has no runtime dependencies of its own, and its NOTICE is the standard ASF one, so the release LICENSE and NOTICE files are unchanged.

Testing

• New SecureXmlParsersTest (5) and two new SafeSAXBuilderTest cases: ordinary namespaced documents parse, document type declarations are refused, declared external entities are not read, and the XML-RPC library uses the same configuration.
• mvn -pl app test on JDK 11: 332 tests, 0 failures, 1 skipped. The suite starts Roller, so the XML-RPC installation runs during it.
• roller.war bundles commons-secure-xml-1.0.0.jar.

Targets roller-6.1.x for 6.1.7. It will be cherry-picked to master after the 6.1.7 release.

[snoopdave]

🐞Claude Issue: PR-Review: General Issues

The following issues were found but cannot be attached to a specific line in the diff:

• Blocking: CHANGES.md on roller-6.1.x is not updated. Add a 6.1.7 entry: XML parsing now uses Apache Commons Secure XML 1.0.0 (new bundled dependency), and Roller now fails at startup instead of logging an error when the XML-RPC parser cannot be configured. Operators should know about that behaviour change.
• Important: No CI runs on this PR, because the roller-6.1.x workflows trigger only for master. I ran SecureXmlParsersTest (5) and SafeSAXBuilderTest (4) locally on JDK 11: all pass. I also confirmed that commons-secure-xml 1.0.0 is on Maven Central with a Java 8 target, and that no other *Factory.newInstance() parser construction remains in app/src/main/java.

[mbien]

looks good

[snoopdave]

🤖Claude:

• CHANGES.md: fixed by adding a 6.1.7 section (not yet pushed). It names the new bundled dependency (commons-secure-xml 1.0.0) and the startup change: Roller now stops at startup when the XML-RPC parser cannot be configured, where it used to log an error and continue.
• CI: not fixed here. Run CI and CodeQL on roller-6.1.x #206 has since added roller-6.1.x to the CI and CodeQL triggers; checks will start after this PR is rebased onto roller-6.1.x.

[snoopdave]

Manually tested on the 6.1.7 integration build (Tomcat 9, JDK 11, MySQL 8). Pass.

• Startup logs no parser configuration errors, and the WAR bundles commons-secure-xml-1.0.0.jar.
• OPML bookmark import works for a plain file. Files with an external entity or an external DTD are refused ("XML document type declarations are not supported"), no blogroll is created, and a local listener received no requests.
• XML-RPC blogger.getUsersBlogs works. Requests with an external entity or DTD return a fault, and nothing is fetched.
• Theme switching and Admin → Configuration load normally.

[ppkarwasz]

The new 1.1.0 version of Commons Secure XML, which is already under vote and will be released today, introduces SecureSAXParserFactory.newNSXMLReader().

[ppkarwasz]

If #198 (comment) is implemented, I don't think there is a compelling reason to disable DOCTYPE. As far as I know, only SOAP and XMPP explicitly ban DOCTYPE declarations.