ContentDecodingChannel closes all InputStreams, which breaks optional<binary> responses

[iamdanfox]

What happened?

@jkozlowski's data storage client has a conjure endpoint which returns optional<binary>. As of conjure-java 5.10.3, the codegen uses a nice new optionalInputStreamDeserializer, but unfortunately the ContentDecodingChannel wrecks us. (this bug arose with conjure-java 5.11.2, dialogue 1.0.2)

Caused by: java.io.IOException: Attempted read on closed stream.
	at org.apache.http.conn.EofSensorInputStream.isReadAllowed(EofSensorInputStream.java:107)
	at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:116)
	at java.base/java.util.zip.CheckedInputStream.read(CheckedInputStream.java:60)
	at java.base/java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:267)
	at java.base/java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:259)
	at java.base/java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:165)
	at java.base/java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:80)
	at com.palantir.dialogue.core.ContentDecodingChannel$DeferredGzipInputStream.getDelegate(ContentDecodingChannel.java:160)
	at com.palantir.dialogue.core.ContentDecodingChannel$DeferredGzipInputStream.read(ContentDecodingChannel.java:188)
	at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
	at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
	at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
	at java.base/java.io.InputStreamReader.read(InputStreamReader.java:185)
	at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
	at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326)
	at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392)
	at org.assertj.core.internal.Diff.linesFromBufferedReader(Diff.java:103)
	at org.assertj.core.internal.Diff.diff(Diff.java:90)
	at org.assertj.core.internal.Diff.diff(Diff.java:52)
	at org.assertj.core.internal.InputStreams.assertSameContentAs(InputStreams.java:71)
	... 24 more

What did you want to happen?

• For the majority of API calls, closing the inputstream is good (i.e. when we're deserializing using jackson)
• When we're returning a raw InputStream or Optional<InputStream> (and perhaps eventually aliases thereof), we need to hand out unclosed inputstreams, so users can actually get the data out at their leisure.