[added] option to not create durable on subscribe

[matthiashanel]

Signed-off-by: Matthias Hanel mh@synadia.com

When exporting/importing say the next subject, the consumer exists already and does not need to be created.
Thus the client should also not try to look it up.

We went down the road of a don't create durable option (1st commit) but altered it to have a dedicated JS create call.
We believe that using BindJetStream might be easier to explain

[coveralls]

Coverage decreased (-0.3%) to 86.685% when pulling 9322734 on no-dur-create into 3b1f6fc on master.

[derekcollison]

Help me understand when this option would be used?

[matthiashanel]

@derekcollison This new call would be used whenever you don't want the client to create durables/streams automagically.
This will help with export/import or when you have restrictive permissions

[derekcollison]

I guess that is what I was looking for clarity on since now we bind to existing durables if they exist and don't always create them, so wanted to make sure I understood the difference in this case.

[matthiashanel]

if you call JetStream then consumer etc will be created.
if you call BindJetStream we assume they exist.

I can add an exception if no durable name was provided an an ephemeral durable needs creating.
comments? @wallyqs

[derekcollison]

When is their a case where you can to have a durable option like we do now but not create?

This because in those situations you do not want the client lib doing its probing to see which direction it should go with a durable etc?

[matthiashanel]

Exactly, when I only export the next subject or have restrictive permissions I want to avoid probing around, as this would fail.

[wallyqs]

As it is, this is replacing the nats.Direct option that used to do something similar to disable using the JetStream API, but instead of being an option it adds a new constructor called js, err := nc.BindJetStream(), that similar to the nats.BindStream() option assumes that there are JetStream streams/consumers are already bound to the current account due to an import for example, so it does not lookup or attempts to create them which can't be done in environments with limited permissions.

[ColinSullivan1]

IIRC, with direct mode there was a potential problem of overlapping acks with duplicate consumers. Does that issue present itself here?

[matthiashanel]

IIRC, with direct mode there was a potential problem of overlapping acks with duplicate consumers. Does that issue present itself here?

@ColinSullivan1 can you explain how this issue showed itself?

[wallyqs]

I think that @ColinSullivan1 means that if you run Subscribe multiple times and they are not a queue subscriber with the same durable name, they can all receive the same message that can be acked.

[wallyqs]

I think whenever JetStream is imported from another account we could refer to it as being bound to the account as an import, LGTM.

[matthiashanel]

@ColinSullivan1 @derekcollison is this change in it's current form ok with you?

[derekcollison]

Let's setup a quick meeting for tomorrow to discuss. You and Colin and I and Wally..

[wallyqs]

Fixed via #740