enforce maxStringLength/maxNameLength read constraints in XML parser

[Sahana2524]

maxStringLength / maxNameLength are ignored when reading XML

The read path never runs the configured StreamReadConstraints over element text, attribute values, or element/attribute/root names, so those two limits have no effect on deserialization even though the write side and the JSON backend honor them. With maxStringLength(100) a 5000-char text value or attribute value parses cleanly, and with maxNameLength(50) a 5000-char element, attribute, or root name parses cleanly.

This complements the maxNestingDepth work in #891 by covering the content-length limits. The checks live where XmlTokenStream materializes each value: validateStringLength at the single text accessor (getText(), which every element-text and attribute value passes through) and validateNameLength at the two name-decode points (_decodeElementName / _decodeAttributeName, which every name passes through). The constraints are threaded in from IOContext. Default limits are unchanged, so normal documents behave exactly as before; maxDocumentLength (#609) is a separate concern and not addressed here.

[github-actions]

🧪 Code Coverage Report

Metric	Coverage
Instructions	77.76%
Branches	71.05%

Coverage data generated from JaCoCo test results

[cowtowncoder]

This only occurs after-the-fact, XML parser having decoded element/attribute name, text value.
Not much we can do there, in general; although Woodstox does provide functionality to limit these at XML parser level.

[Sahana2524]

Agreed, this is a post-decode check: by the time getText() or the name decode runs, the Stax reader has already buffered the whole value, so it doesn't bound memory inside the XML parser the way Woodstox's P_MAX_TEXT_LENGTH / P_MAX_ATTRIBUTE_SIZE do. What it does buy is that a configured StreamReadConstraints isn't quietly ignored on the XML side, it applies whichever Stax implementation is underneath (along the lines of your note on #891 about not leaning on Woodstox's depth limit alone), and the value is rejected during nextToken() with the same StreamConstraintsException the JSON backend throws, before databind consumes it. If you'd rather not carry it, or want the javadoc to say explicitly that the Woodstox properties are the parser-level guard, I can adjust either way.