throw checked exception if growArray has a size that is too big

[pjfanning]

• useful as a check in its own right
• also improves behaviour in Add configurable limit for the maximum length of Object property names to parse before failing (default max: 50,000 chars) #1047 case
  • I'm not saying that there shouldn't be a max element name length
  • just that this change sorts out the case where you have a crazy long element name - you get a checked exception (StreamConstraintsException) instead of a java.lang.NegativeArraySizeException

[cowtowncoder]

Hmmmh. As per my comment, I don't like the idea of API exception from general-purpose helper.
I am bit meh on checking in general, actually, since it seems unlikely this would be hit. But I guess it's fine.
I'll merge & change exception type.

[pjfanning]

@cowtowncoder The point is to use a checked exception (ie not an exception that extends RuntimeException). Unfortunately, the people who are obsessed with getting CVEs assigned to everything are obsessed about unchecked exceptions. They go bananas when an exception or error occurs that is not part of the API signature. That spring-boot user was upset that jackson failed with java.lang.NegativeArraySizeException.

If StreamConstraintsException is a problem, could we use IOException?

[cowtowncoder]

@pjfanning Let's add proper name size constraints checks and not rely on array expansion exhausting max array size. This is not the way to fix problems -- decoding will become problem way way before int32 exhausts.

EDIT: if we run out of time for release or such, we can change the exception to StreamReadException -- but only in that case. Otherwise let's try to get proper check if at all possible.