Add `StreamReadConstraints` limit for longest textual value to allow (default: 5M in 2.15.0; 20M in 2.15.1)

[cowtowncoder]

So, similar to #827 there should be some upper limit for length of String values. We can start with something rather long -- 5 megs -- since the handling of textual values is not nearly as sensitive to input length as that of numeric (in particular floating-point). And also because there are likely use cases that rely on ability to process sizable Strings (different from numbers once again).

Different from number constraints we can and should apply limit during accumulation of textual value, into TextBuffer (either within it, or maybe more likely, when caller fetches new local char[] buffer). The idea being that we do want to avoid processing of the whole String before failing.
This would probably mean that the limit applies to char length after entity resolution. That should be fine too; the goal is not to impose byte-accurate limits but to prevent overloading.

Note: this is also distinct from total document length limit that we likely want to impose too, eventually.

EDIT: (21-Mar-2023) 2.15.0-rc1 had limit of 1M, rc2 planned to use 5M. Updated description and title accordingly.
EDIT/2: 2.15.1 raised default limit to 20M
EDIT/3: (20-May-2025) see #1019 for globally configuring default limit, in case you cannot properly configure JsonFactory instances.

[cowtowncoder]

cc @pjfanning Just creating placeholder, based on our discussions. Even at the risk of security mongerers reading this :)

[pjfanning]

this one may not be that useful - users would be better off setting a max length on the JSON stream that they will accept

[cowtowncoder]

@pjfanning I am not sure -- I guess I am considering bigger streaming use cases (where total content length cannot be easily limited), although granted those would probably not accept external untrusted input.