Fixed infinite loop described in INT-3453.

Fixed an infinite loop in the `getNextBuffer()` method of `ChannelInputStream`.

JIRA: https://jira.spring.io/browse/INT-3453

I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
This is the race condition I am talking about...

    reader sets writing to pipe
    starts an assembler (or there's one already running)
    reader writes to the pipe
    assembler immediately consumes the data, sees 'dataAvailable' (because writing to pipe is still set) and schedules another assembler (or himself via the new loop).
    reader resets writing to pipe

So we end up with an assembler waiting in `getNextBuffer()` when none will arrive (until the client sends some more).

The sleep you added gives us a second chance in case writing to pipe was still true even though the reader had already written.
    

I added `writingToPipe` some years ago to avoid the reverse situation - where we started the assembler but there was no data (yet) in the pipe so he exited immediately. It's meant to signal to the assembler that although there's no data in the pipe, some is coming, but clearly it's flawed on the back-end after the reader has written to the pipe, but hasn't yet cleared the flag.