Change of behavior (2.8 -> 2.9) with `ObjectMapper.readTree(input)` with no content

[cowtowncoder]

So, it looks like readTree() methods in ObjectMapper, ObjectReader that take input OTHER than JsonParser, and are given "empty input" (only white-space available before end), will

• Return NullNode (Jackson 2.x up to and including 2.8)
• Return null (Jackson 2.9)

Latter behavior is what readTree(JsonParser) has and will do; but this accidentally changed other methods due to refactoring that unified underlying call handling (and add checking for new DeserializationFeature.FAIL_ON_TRAILING_TOKENS).
Behavior for this edge case was not being tested, apparently.

Now: since behavior has been changed for all 2.9.x patch versions, I am not sure it should be changed for 2.9 branch. But it seems sub-optimal as behavior, and something to definitely change for 3.0... but probably also for 2.10.

There are multiple things we could do.

1. Change it back to 2.8, to return NullNode
2. Change to throw exception, as "not valid" use case
3. Change it to return MissingNode
4. Leave as-is, for rest of 2.x.

Although it might seem best to revert it to (1), that seems somewhat wrong, problematic, as it would now not be possible to distinguish between JSON null value and missing content.
And although (2) would probably make sense, if designing API from scratch, it is probably too intrusive.

So I think (3) is the best way: it avoids returning null or throwing Exception (both being likely to break 2.9 code), but still allows distinguishing between all possible input cases.

[cowtowncoder]

Note: once upon a time there was #1406, which actually makes this intentional but misguided change.