Add sendMessages and flush to StreamingRequestClientCall

[glbrntt]

Motivation:

The API for StreamingRequestClientCall does not make it easy for users
to send a batch of messages and then flush at the end.

Modifications:

Add methods to StreamingRequestClientCall to:

• send messages, and
• manually flush.

Result:

Users can send a batch of messages and manually flush for calls which
stream from the client.

[glbrntt]

Resolves #537

[MrMage]

Should we have the same methods on the server as well?

[glbrntt]

Should we have the same methods on the server as well?

Potentially, but I think it would come with a broader set of changes: at the moment there's really no control for the user in how they send messages, only sendResponse(message:) -> EventLoopFuture<Void>.

I'll file another issue for this.

[MrMage]

Thinking about this more, what's the benefit of the extra flush: argument over calling flush()? Sorry if I missed that before.

I'm a bit worried that having both future-returning and promise-taking methods that both have a flush: argument might start to get a bit confusing and violate the single responsibility of just sending a message.

[MrMage]

LGTM, save for my question about flush: before.

[glbrntt]

Hmm I see your point.

We should keep the future/promise APIs. But I think we can do away with flush() and flush: and just always flush in sendMessage/sendMessages.

I think it's a reasonable assumption to make that most users will send a single message at a time in which case I think they'd (probably) want to flush as well. If they don't want to flush when writing a message then they can keep their own buffer of messages and then send them with sendMessages.

The API would then be something like:

• sendMessage(_ message: RequestMessage) -> EventLoopFuture<Void>
• sendMessage(_ message: RequestMessage, promise: EventLoopPromise<Void>?)
• sendMessages<S: Sequence>(_ messages: S) -> EventLoopFuture<Void> where S.Element == RequestMessage
• sendMessages<S: Sequence>(_ messages: S, promise: EventLoopPromise<Void>?) where S.Element == RequestMessage

What do you think?

[MrMage]

We should keep the future/promise APIs. But I think we can do away with flush() and flush: and just always flush in sendMessage/sendMessages.

Agreed.

The API would then be something like:

Looks good to me :-)