Add configurable limit for the maximum length of Object property names to parse before failing (default max: 50,000 chars)

[cowtowncoder]

(note: part of #637)

Similar to token-length limits for Numbers (see #815) and Strings (see #863), we need an option to limit maximum Object Property name length to something reasonable, as otherwise name tokenization can become performance issue for very long names.

As with other limits, units would related to underlying input units -- bytes or chars depending on input source.

We need to decide on reasonable defaults to use: my initial suggestion is to limit to 64k but this probably needs to correlated to:

1. Performance-characteristics (can we find a pivot point where length increase has super-linear negative effect?)
2. Longest legit (non-malicious) property names used in the wild.

That is: figure out highest limit that works for DoS aspect, balanced with lowest limit that would be unlikely to break existing legit usage.

[ghost]

I am also in favor of this ticket, as I wrote in this comment: #1014 (comment)

[cowtowncoder]

@AlessandroPerucchi note that there is already ability to change existing limits: this would introduce one more limit.

[yhojann-cl]

Related issue: spring-projects/spring-boot#36666 the key names are not controlled and produces an integer overflow when try copy the byte array. Confirmed in Java Spring Framework.

[cowtowncoder]

Quick note: based on simple local testing with longer names, it looks like performance of, say, 1_000_000 (ascii) bytes/chars decoding is not superbly bad -- actually, unit test with cold start seems to process doc with 10 meg name in about 150 msecs. And although other factors (escaping, UTF-8 chars) no doubt change things (quick testing with escapes and 2-byte chars actually increases time to almost 500 msecs), I think we can -- if we want to -- allow larger names than 50k, by default, if we want to.

I'll see if I can find limits other processors impose.

[cowtowncoder]

Implemented via #1078.