Fix Java IterableByteBufferInputStream to return -1 on empty

[niloc132]

This gives the InputStream slightly less work to do when it knows there are no buffers that can be checked for more data.

Also loosened a check in CodedInputStream to permit read() to return zero, as this is documented as a valid value - though in this case -1 is the correct value as there is nothing more to read.

Fixes #23957

[zhangskz]

Why was this changed? I don't think this seems necessary.

[niloc132]

It isn't the only correct way to fix it, but something like this should probably be done. While returning 0 from read() is not wrong, it is also not correct for this case - the return value 0 means "zero bytes were read this time", but the return value -1 means "this is the end, there is no more data to read, do not try again".

If we just go with the relaxed check in CodedInputStream, it would technically be correct to keep trying to ask for more data, because 0 only means that this read found nothing, but not yet reached end of stream.

It could also be correct to instead assign dataSize to be 0, so that it matches currentIndex. The bug is that in both overloads of read(), the two must be equal, or we don't return -1 right away (which would be correct, since there is no more data to read and there never will be). But since dataSize is never assigned outside the constructor, it seems more appropriate to advance currentIndex to meet dataSize, rather than change dataSize to match whatever currentSize we happen to be at (in the case of the bug, one past the end of dataSIze, so we fail the checks at the top of the read()s).