Optimize `UntypedObjectDeserializer` wrt recursion [CVE-2020-36518]

[cowtowncoder]

EDIT: related to to CVE-2020-36518 (see https://nvd.nist.gov/vuln/detail/CVE-2020-36518)

EDIT: Fix included in

• 2.14.0
• 2.13.3:
  • Was also included in 2.13.2.1 and 2.13.2.2 (see https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13); to be used with jackson-bom version 2.13.2.20220328
• 2.12.6.1: (see https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.12)
  • use with jackson-bom version 2.12.6.1.20220326

EDIT: included as one of Snyk's "top-10 vulns of 2022" CVEs -- see https://go.snyk.io/snyk-top-10-open-source-vulnerabilities-dwn-typ.html

---

Current implementation UntypedObjectDeserializer is relatively expensive for deeply nested Object and Array values as it uses recursion even for "vanilla" case (one where there are no custom List/array or Map deserializers).
In practical terms it is possible to exhaust typical modest JVM memory with documents having about ten thousand levels of nestings, due to size of call stack from recursive calls.

NOTE: specifically this ONLY APPLIES if the target type is "untyped" or generic Collection<Object> / Map<String, Object> -- it DOES NOT APPLY to cases where target is POJO (except if POJO itself has "untyped" property or properties).

Similar issue was already solved wrt JsonNode (see #3397), included in 2.13.0; this might show a way to approach this problem: by replacing simple recursion with iteration, either completely or at some inner levels.

Also note that it may ultimately be necessary to have lower-level constraints for streaming parser too, see: FasterXML/jackson-core#637

Ideally it should be:

1. Possible to handle at least tens of thousands of levels of nesting (100k should be processable with 256M heap, say)
2. Have streaming level limits that -- by default -- block documents with more than limit we deem safe (less than 100k -- perhaps 10k or something, to be determined).

This issue is specifically about (1) as (2) is about jackson-core.

[cowtowncoder]

Looks like nesting of about 2000 works, 3000 fails, with default settings for both Arrays and Objects.

[cowtowncoder]

Tagging as "performance" (since resource consumption of call stack causes the exception). Also added similar test for JsonNode. Hoping to eventually tackle for these types but realistically support from streaming parser (jackson-core) is probably needed (will file separate ticket) for more general complexity limits for input documents.