Twitter Decoder cannot handle all InputStream implementations

[pjfanning]

See https://github.com/twitter/hpack/issues/43

Works fine with ByteArrayInputStream but breaks if you use SequenceInputStream.

It is unlikely that the twitter/hpack issue will be fixed.

We could modify our fork of the HPack Decoder to avoid using available() method by

• adding private methods boolean isEndOfStream() and byte nextByte()
  • one implementation is to read one byte ahead
  • read into a byte array and keep track of the pos and remaining bytes and refresh the byte array when remaining is zero
• find an InputStream implementation that we can use to wrap the provided stream but that gives us a way to work out if we are at the end of the stream without consuming bytes

[jrudolph]

The easiest solution is to keep everything as it was because the potential performance improvements are somewhat dubious in the first place. The premise of the improved implentation is that the incoming Bytestring already is fragmented (which is not the case in the common scenario of receiving the full HEADERS frame in one go from the network). In the case that multiple Bytestringss have to be collected before header decoding, it might still be more efficient to do a compact first than iterating over the fragments (cache effects vs more complicated looping). So the only potential improvement could be removing a simple memcpy by avoiding a compact call which may or may not be a significant change.