changing the acknowledgement interface about pulsar-rs

[Geal]

I'm starting multiple PRs on this, to see how the interface would feel

[Geal]

I'm running into another issue: it is not possible to send acks asynchronously, because there's no answer to that message: ConnectionSender has a channel to connection::Sender, and then the sender will receive from that channel and send message on the TCP connection. There's no way to await until the message is actually sent, since we can either call unbounded_send on the channel (sync interface) or using SinkExt::send but it requires mutable access (it should be possible to make it mutable).
Right now, for most messages, awaiting is done by sending the message with a request key, giving a oneshot sender to the connection::Receiver instance, and waiting on that oneshot channel.

Since connection::Sender is mainly wrapping the connection's sink, it should be possible to remove it and directly hold the sink in the ConnectionSender

[Geal]

ok, so, after more investigation, there's an issue with the UnboundedSender in Ack that is used to communicate with the Ackhandler: it does not detect that the AckHandler dropped the receiver, so calling Ack::ack() does not fail. Closing the channel from the sender side before calling close_consumer() is enough to make ack() fail as expected

[Geal]

with #82 it gets more manageable: acknowledgements are done only through the consumer, so we cannot try to ack a message after the consumer was dropped.

Possible issues:

• it is not possible to acknowledge messages after converting the consumer to a stream (with method like take(), etc). I believe the main case will be in while let Some(message) = consumer.next.await { }, but still, we should not forbid other patterns. For cases like this, we could add options to either:
  • automatically acknowledge messages as they're taken from the stream
  • send a cumulative ack for all previously seen messages when the consumer drops
  • provide a separate object that could acknowledge messages, like the previous Ack, but linked to the Consumer, not to the message
• acks are not batched now, but I'm planning to add an ack methods that take a list of messages or message ids to acknlowedge all of them at once

[Geal]

done in 1.0 release