Race condition causes header frame to be fired on HTTP2StreamChannel AFTER first data frame(s) about swift-nio-http2

[FranzBusch]

From a quick look this looks like a reentrancy problem where as you pointed out we can re-order reads. This is a bit of an interesting one since anything can potentially happen between these two method calls

channel.configureInboundStream(initializer: self.inboundStreamStateInitializer)
channel.receiveInboundFrame(frame)

I am wondering if we could just reorder those two calls so that the read gets buffered before we configure the stream channel; however, I am deferring this to @Lukasa who is more familiar with the insides of our H2 stack.

[Lukasa]

Note that tryToAutoRead does not itself end up triggering a call to HTTP2CommonInboundStreamMultiplexer.receivedFrame. This can only happen if we hit the following series of events:

1. HTTP2StreamChannel.read0
2. unsatisfiedRead is false, so we set it to true.
3. self.pendingReads.count == 0
4. Leading to a call to self.parent?.read()
5. This calls read on the parent channel.

So I think the reason this hasn't happened to anyone else is that it's very uncommon for read() to actually unbuffer a channelRead message. Typically it only sets flags that are operated on the next EL spin. This is not always true, however: some channel handlers will buffer up data that is freed on a read call, which might be happening to you. However, as most HTTP/2 handlers operate directly on socket channels, read is not going to synchronously trigger a read system call, and so will not emit more data directly.

Franz's suggestion of a fix seems appropriate: we can safely buffer up that headers frame and then hit the configure flow. @qusc would you like to write a test for this? You'll need to use a custom ChannelHandler to trigger the re-entrancy on read. You're then also welcome to fix the issue.

[qusc]

Thanks for your support! Let me know if the fix and test case I added to my pull request are implemented appropriately @Lukasa