Fix WFS property format writer for multiline strings

[aboulan]

When updating a feature through WFS, if there are any newline
characters in a string properties, these are lost (for example,
geoserver handles these newlines as whitespace).

To fix this, multiline string properties should be encoded as
CDATA block.

Fix #10127

[github-actions]

📦 Preview the website for this branch here: https://deploy-preview-15638--ol-site.netlify.app/.

[ahocevar]

Suggested change

	if (typeof pair.value === 'string' && pair.value.search('\n') >= 0) {
	if (typeof pair.value === 'string' && pair.value.includes('\n') >= 0) {

The above should work as well, and yield better performance because no regular expression is created.

[rdewit]

Did you mean to remove the >= 0 part as well, @ahocevar, like below?

Suggested change

	if (typeof pair.value === 'string' && pair.value.search('\n') >= 0) {
	if (typeof pair.value === 'string' && pair.value.includes('\n')) {

[ahocevar]

Yes, thanks @rdewit

[aboulan]

When looking at the issue more closely, I wonder if it wouldn't be better to completely skip the test and always output a CDATA block.
Indeed, it is not only end of lines that are not correctly interpreted in a text node: any white space combination (space, tab, end of line) is interpreted as a single space (as per the html/xml rules), so that for example a string with multiple consecutive spaces is also not correctly handled.
But using CDATA blocks are not the perfect solution either: they cannot contain the end of block sequence ("]]>").
They also cannot contain arbitrary binary data (it must be a valid utf8 string) but this is probably not a problem since WFS property values are supposed to be valid xml text (but I don't know if the WF specs explicitly says something about this)
For simple use cases (multi-line string, which I needed initially), CDATA blocks are working great out of the box with geoserver (and any xml parser), but maybe the correct solution for the general case would be to have an API to let the user handle the serialization himself (base64 ?)
What do you think?

[aboulan]

The following may be the best compromise to catch any white space combination without using CDATA blocks for single words:
[ ' ', '\n', '\t' ].some(c => pair.value.includes(c)

[ahocevar]

Fine with me to always create a CDATA block.

[M393]

If you have text with ]]> end marker included you can write multiple CDATA sections by splitting the end marker.

pair.value.split(']]>').forEach((part, i, a) => {
  if (i < a.length - 1) {
    part += ']]';
  }
  if (i > 0) {
     part = '>' + part;
  }
  writeCDATASection(value, part);
});

[ahocevar]

Not sure if it would work, but how about

Suggested change

	try {
	// Generate a CDATA section to preserve whitespaces.
	writeCDATASection(value, pair.value);
	} catch {
	// If value contains the CDATA closing marker ']]>', fallback to a text node.
	writeStringTextNode(value, pair.value);
	}
	pair.value.split(']]>').forEach((text) => writeCDataSection(value, text));

[aboulan]

Sorry I thought I already made the change following @M393 's remark but failed to push correctly.
Should be good now.

[ahocevar]

I think this addition could benefit from a test case.