Ignore DOCTYPE inside a multi-line comment body

[junhyeong9812]

Overview

XmlValidationModeDetector peeks at the start of an XML document to decide between
DTD- and XSD-based validation by looking for a DOCTYPE declaration, while skipping
any DOCTYPE text that appears inside XML comments.

Problem

The comment-skipping logic does not fully account for the multi-line "in comment"
state. consumeCommentTokens(String) short-circuits a line that contains neither a
start (<!--) nor an end (-->) marker by returning it unchanged:

int indexOfStartComment = line.indexOf(START_COMMENT);
if (indexOfStartComment == -1 && !line.contains(END_COMMENT)) {
    return line;
}

When the parser is already inside a multi-line comment (this.inComment == true),
such a line is the body of the comment, yet it is returned verbatim as content. If
that body line contains the text DOCTYPE, hasDoctype(content) matches and the
document is misdetected as DTD-based.

<?xml version="1.0" encoding="UTF-8"?>
<!--
  See the DOCTYPE notes for legacy configs
-->
<beans .../>

detectValidationMode() returns VALIDATION_DTD for this XSD document instead of
VALIDATION_XSD.

This is the residual case left by the fix for #27915 (DOCTYPE in a comment): that fix
covers comments whose markers sit on the same line, but a marker-less body line of a
multi-line comment still leaks through the early return above. Note the asymmetry —
hasOpeningTag(String) already guards with if (this.inComment) return false;, but
the comment-consumption path does not.

Fix

Honor the "in comment" state in the early return so a comment body line is treated as
empty content rather than leaking out:

if (indexOfStartComment == -1 && !line.contains(END_COMMENT)) {
    // If we are inside a multi-line comment, the entire line is comment
    // data and must not be treated as content.
    return (this.inComment ? "" : line);
}

This addresses the documented contract of consumeCommentTokens ("returns the
remaining content, which may be empty since the supplied content might be all comment
data ... takes the current 'in comment' parsing state into account"). A regression
fixture (xsdWithDoctypeInMultiLineCommentBody.xml) is added to the existing
parameterized xsdDetection test.

Note

If you'd prefer a belt-and-suspenders approach, a symmetric inComment guard could
also be added to hasDoctype(String) (mirroring the existing guard in
hasOpeningTag(String)) so that a DOCTYPE match is never honored while inside a
comment, regardless of how the content was produced. I kept this PR to the single
root-cause change to stay minimal, but I'm happy to add that guard as well if you
think it's worthwhile.

Related Issues

• Spring fails to determine XML is XSD-based if DOCTYPE appears in a comment #27915