fix(jetty): vendor patched upstream/etc/jetty.xml to silence 'Ignored arg' warning

[natechadwick-intsof]

Summary

Silences the Ignored arg <Arg name="threadpool"><Ref refid="threadPool"/></Arg> WARN that the bundled Jetty 9.4.58.v20250814 distribution emits on every startup, by vendoring a patched upstream/etc/jetty.xml into system/Tools/jetty/upstream/etc/jetty.xml.

Why

The line is in the file the upstream Jetty distribution itself ships — it's not something our security/hardening work added. org.eclipse.jetty.server.Server in 9.4.58 declares its only ThreadPool constructor parameter as pool, not threadpool, and the bytecode doesn't carry MethodParameters (verified with javap -p -v). Jetty's XmlConfiguration matches <Arg name="..."> to constructor parameters by name; with no parameter name available at runtime the arg is logged as ignored and the Server() no-arg constructor is used instead, creating a default QueuedThreadPool.

The WARN is benign in the sense that startup succeeds and the server runs, but it's noisy and the root cause is real (the upstream file's name="threadpool" does not match the constructor's pool parameter in 9.4.58+).

How

1. Added a full vendored copy of upstream/etc/jetty.xml at system/Tools/jetty/upstream/etc/jetty.xml with the offending <Arg> replaced by a comment block explaining the why (so a future Jetty upgrade reader doesn't re-add it).
2. The antrun copy task in modules/perc-jetty/pom.xml (phase process-resources, third sub-task) overlays system/Tools/jetty/ onto ${assembly-directory} after the upstream Jetty distribution is unpacked, so the vendored file wins. The pattern matches the existing system/Tools/jetty/upstream/lib/jetty-webapp-9.4.26.v20200117.jar vendoring for the CMS-6724 fix.

Behavior

• Before: Server starts, the Ignored arg ... WARN is logged, the Server() no-arg constructor is used, a default QueuedThreadPool is created (minThreads=8, maxThreads=200). The threadpool Jetty module's threadPool bean is created but not bound to the Server.
• After: Server starts, the WARN is gone, the Server() no-arg constructor is used (same as before), a default QueuedThreadPool is created (same as before).

No runtime behavior change. The vendoring is purely cosmetic from a runtime standpoint; the substantive change is the documentation of why the line isn't there.

Side finding (separate, NOT in this PR)

The threadpool Jetty module's custom-configured threadPool bean (minThreads=10, maxThreads=200, idleTimeout=60000, detailedDump=false) is not currently bound to the Server — it was never being applied, even before this fix, because the upstream <Arg> was being ignored. If we want the module's config to actually take effect, the right XML change is to drop the name attribute (<Arg><Ref refid="threadPool"/></Arg>) so XmlConfiguration matches by position. That's a deliberate behavior change (minThreads goes from 8 to 10) and should be a separate, focused PR with its own verification.

Verification

• python3 -c "import xml.etree.ElementTree as ET; ET.parse('system/Tools/jetty/upstream/etc/jetty.xml')" → well-formed.
• diff between vendored and upstream is only the one <Arg> line and its 17-line replacement comment.
• After rebuild of modules/perc-jetty and redeploy: grep "Ignored arg" jetty/base/logs/server.log returns no matches. The startup log is otherwise unchanged.

Refs #206

Co-Authored by Mavis Mavis-Code using MiniMax-M3 with agent mavis.