reject negative UTF length in LongUTFDataInputStream.readLongUTF

[aizu-m]

readUnsignedShortOrInt falls back to a signed readInt for the 0xfffe marker so the modified-UTF length can arrive negative, and it flows straight into new StringBuilder(utfLen/2) which throws NegativeArraySizeException out of StringPool.readFrom and crackPointer (both catch only IOException) instead of the SchemaTypeLoaderException the loader is contracted to use; rejecting a negative length as a UTFDataFormatException matches the malformed cases already handled in this method and lets the existing IOException catch wrap it.

[pjfanning]

these are not public APIs - these changes cause performance degradations - do we really need them? - if it isn't clear that the internals of XMLBeans are for internal use, we can improve the docs

[aizu-m]

Fair point, it's an internal class and the only realistic trigger is a corrupt or tampered .xsb on the classpath. I hit it while fuzzing the string pool loader, same path as #88 and #89. Cost-wise it's one int compare per pooled string at schema load, nothing on the parse or save paths, so I don't think it's measurable, but I take the point that each of these adds up. If you'd rather not carry it, I'm fine with this being closed.

[pjfanning]

Ok. I'll merge this. I'm not worried about hacked xsb files - if you can hack them, then you can hack classes.
I still don't regard this as a big improvement in this lib and it fights against a basically non-existent problem.
I don't care what the fuzzer is doing, it is generating garbage.

[aizu-m]

Understood, and thanks for merging it.