Fix InputStreamResponseTransformer feedback

In short, the problem with the previous version was that the throttling didn't take into account how much we had previously requested, and thus it would over-request data by at least 10x.

The somewhat longer version is that when we receive (or finish) a chunk of the response, and we are below the threshold, we request 10 more chunks. With the threshold set to 32MB, and the typical chunk size set to 1500, we will have process well over 22k chunks before we reach the threshold. Each and every one of these times, we will request 10 additional chunks (plus an additional 10 if the chunk was non-empty and we finished it before reaching the threshold). This means that we will sign up for 10x the number of chunks required to reach the threshold, and we will buffer up to that amount, as there is no means of telling the producer we want less. Assuming the chunk sizes stay consistent, this behavior is actually independent of the actual chunk sizes.

By changing the number of chunks we request to 1, it means we only grow the number of in-flight chunks when finishing a chunk, but since we check the threshold at this location as well, and only increase by 1 here as well, we can't really overshoot.

One potential drawback with this approach is that the ramp-up in buffer size will be dependent on the rate and amount of data processing.

src/main/java/io/burt/athena/result/s3/InputStreamResponseTransformer.java

@@ -82,7 +82,7 @@ public void onNext(ByteBuffer byteBuffer) {
 
     private void maybeRequestMore(int currentSize) {
         if (currentSize < TARGET_BUFFER_SIZE) {
-            subscription.request(10L);
+            subscription.request(1L);
         }
     }