performance(kie-dmn-feel): Performance regression in Drools v10+ with DMN models - #6871

Closes #6870

Fix significant performance regression in matches() and replace() FEEL functions (DMN)

Problem

After upgrading from 8.44.x to 10.x, users observed a ~60% increase in execution time on
large DMN workloads (e.g. 200 s → 315 s on 400k-row batches). The bottleneck was traced to
XQueryImplUtil, which is called on every invocation of the FEEL matches() and replace()
functions.

Two independent inefficiencies were introduced:

1. new Processor(false) on every call (commit 8dac313): Saxon's Processor constructor
   initialises the entire Saxon configuration and performs a license check. Creating it per call
   cost ~60 ms per 2,000 rows on Saxon 12.x. Saxon's own documentation recommends one Processor
   instance per JVM.

2. Multi-pass string escaping: escapeXmlCharactersReferencesForXPath() scanned the input
   string up to 11 times (one regex guard scan + one contains + one replace per special
   character), creating up to 5 intermediate String allocations per call. This is invoked 2–3
   times per matches()/replace() call, so the cost multiplied across the batch.

Changes

XQueryImplUtil.java

• Extracted Processor and XQueryCompiler into private static final fields — one instance
  per JVM, shared across all calls. Both are thread-safe per Saxon's API contract.
• Rewrote escapeXmlCharactersReferencesForXPath() as a single-pass StringBuilder loop with
  lazy allocation: no StringBuilder is created at all when the input contains no special
  characters (the common case in DMN), and the original String reference is returned unchanged.
  The Pattern field and java.util.regex import are no longer needed and have been removed.

XQueryImplUtilTest.java

• Added 15 new test cases covering: explicit empty flags, multi-flag combinations (si, mi),
  all five XML special characters in input and pattern, special characters in replacement strings,
  and backreference syntax — ensuring the full escape→embed→evaluate pipeline is exercised
  end-to-end against Saxon.

Measured impact (Saxon 12.10, 2,000 rows/run, median of 5 runs)

Extrapolated to a 400k-row batch: ~13–17 s → ~1–2 s per workload type.

We used a manual warm-up benchmark to measure the regression. The results show a consistent 7–12× improvement across all workload profiles. Results in production could be different.