[DRAFT] check for nesting limits

[pjfanning]

• Relies on Add StreamReadConstraints.maxNestingDepth() to constraint max nesting depth (default: 1000) jackson-core#943 to compile.
• I need to find a way to test the TreeTraversingParser and TokenBuffer changes

[pjfanning]

@cowtowncoder I was trying to add a test that checks the new logic in TreeTraversingParser (to validate nesting depth constraint). I found that 'readTree' validates already because it uses the jackson-core ReaderbasedJsonParser. I had to change the mapper to loosen the default nesting constraint to get this line to pass. This got me to thinking. Is there much point in having TreeTraversingParser also validate the nesting depth?

A similar question could be asked for the TokenBuffer Parser.

[cowtowncoder]

@pjfanning Good question: I don't think they should (have to) validate nesting depth: only things that read actual input should. It seems like pure overhead, plus in some cases it may be unclear which constraints to use.
Same sort of goes for String length checks too I suppose.

One counter-case might be numeric length: if buffering String tokens but requesting number, number-length checks should be applied.

[cowtowncoder]

@pjfanning Let's just remove validation checks from TreeTraversingParser and TokenBuffer -- they cannot be used in a way (AFAIK) that could cause issues, at least now with reading (all content comes from a validating source).
Writing will use different codepaths, checks, but I don't think that'd be problematic either (since content will end up into validating sink/target).

I'll try merging some of changes from here to unblock some tests.

[cowtowncoder]

Ok, merged unit test fixes directly. Caused some conflict, will try to resolve.

EDIT: no more conflicts.

[pjfanning]

useful bits already merged - #3810 contains the test