Lift requirement to create streams in order

[Lukasa]

In swift-nio-http2 today we have an unspoken hard requirement, which is that if you call createStreamChannel multiple times you must send the first write on each of those channels in the order you created them. This is because createStreamChannel allocates a stream ID immediately for each of those channels, but that allocation isn't meaningful until we try to write to the network. If you write out of order, the later streams will use the higher stream ID allocated to them, and will implicitly retire the lower IDs used by the earlier channels. When those earlier channels try to send, the core state machine will reject them for violating stream ID ordering.

After discussing with @glbrntt we think this is made up of several changes:

• Define a new internal protocol: HTTP2FrameConvertible. This is a protocol that encapsulates creating HTTP2Frames from a given object and vice-versa. We will have two conforming types: HTTP2Frame (trivial) and HTTP2Frame.Payload (straightforward, but not trivial). (Add HTTP2FrameConvertible and HTTP2FramePayloadConvertible #216)
• Define a new protocol: HTTP2FramePayloadConvertible. This is the inverse of the previous protocol: creates a payload from the given object, or vice versa. (Add HTTP2FrameConvertible and HTTP2FramePayloadConvertible #216)
• Make HTTP2StreamChannel generic over an outbound payload type conforming to HTTP2FrameConvertible. This will become the inbound and outbound message type. This requires updates to the various inbound and outbound reading and writing functions. This should not require any interface changes on the interface between the multiplexer and the stream. The multiplexer will need to be updated to hold the new type (HTTP2StreamChannel<HTTP2Frame>). (Make HTTP2StreamChannel generic over a message type #218)
• Define a struct that provides the interface HTTP2StreamMultiplexer expects from HTTP2StreamChannel, that holds the channel privately. This should be backed by an enum, which we will use later to add a new case for the new channel type. Refactor HTTP2StreamMultiplexer to use this type. (Define abstraction for multiplexer holding channel. #215)
• Update HTTP2StreamChannel to tolerate its streamID being optional, and nil on initialisation. This requires a new function on HTTP2StreamMultiplexer to get the next stream ID, which is currently done in createStreamChannel. (Update HTTP2StreamChannel to tolerate nil stream ID. #217)
• Add a new createStreamChannel function with a new initializer that no longer gets a stream ID. Plumb through this initializer to create new stream channels that use HTTP2Frame.Payload instead of HTTP2Frame. Update the enum created above for the new case. (Allow payload-based stream channels to be created. #221)
• Update the codecs to become generic over HTTP2FramePayloadConvertible, and rename them. Create typealiases for both the old version (keeping its old name) and the new one that uses HTTP2FramePayload. Deprecate the old typealias. (Add HTTP2Frame.FramePayload codecs #222)
• Deprecate the old interface, including replacing anything in the HTTP2PipelineHelpers function to use the new initializer. (Add new pipeline helpers and deprecate old paths #226, Deprecate the HTTP2 to HTTP1 codecs #227)

[sweetbot]

Just to understand the ETA: with #222 being merged, when could we see a new version of swift-grpc and close this issue grpc/grpc-swift#912?

[glbrntt]

@sweetbot there are still outstanding tasks to resolve this issue before we can tag a release of SwiftNIO HTTP/2. gRPC will then need to pick up the new version and any new changes that come with it. My hope is that we can tag a gRPC release by the end of the week.