Adding HTTP/2 application-level inbound flow control support.

Motivation:

Currently the DefaultHttp2InboundFlowController only supports the
ability to turn on and off "window maintenance" for a stream. This is
insufficient for true application-level flow control that may only want
to return a few bytes to flow control at a time.

Modifications:

Removing "window maintenance" interface from
DefaultHttp2InboundFlowController in favor of the new interface.

Created the Http2InboundFlowState interface which extends Http2FlowState
to add the ability to return bytes for a specific stream.

Changed the onDataRead method to return an integer number of bytes that
will be immediately returned to flow control, to support use cases that
want to opt-out of application-level inbound flow control.

Updated DefaultHttp2InboundFlowController to use 2 windows per stream.
The first, "window", is the actual flow control window that is
decremented as soon as data is received.  The second "processedWindow"
is a delayed view of "window" that is only decremented after the
application returns the processed bytes.  It is processedWindow that is
used when determining when to send a WINDOW_UPDATE to restore part of
the inbound flow control window for the stream/connection.

Result:

The HTTP/2 inbound flow control interfaces support application-level
flow control.
It seems like an interesting case where we are relying on the user to supply how much of the data was "processed" (which we use to restore the window), but if something goes wrong we assume they have processed all of the data?

I think I agree with your approach (I can't think of a better alternative :).  I think the options are:
1) Do what we are doing now.
2) Restore none of the window.  As you said this may be more difficult for the user to detect and recover from.