[ADDED] Ability to suppress echos from your own connection

[derekcollison]

Resolves #453

/cc @nats-io/core

[coveralls]

Coverage increased (+0.1%) to 92.425% when pulling 535367e on echo into e17ccb8 on master.

[kozlovic]

LGTM

[derekcollison]

I want to check on how clients interact with older server. May want to bump proto like we did for async INFO to allow clients to check before sending and not getting the result they want.

[kozlovic]

Ok, that would work on a connect where we can fail the connection saying that the server is not supporting that feature, but for a reconnect, what do we do? Say you connect to a server supporting echo, then it stops and the next server does not. Do you fail the reconnect?

[derekcollison]

I would expect that to be a rare situation, but let me think about it. Client could through async err indicating echo not supported on connected server. More client work I think.

[kozlovic]

LGTM

[aricart]

the main issue with this feature being a client option is that, if the server doesn't provide the feature, and the option is set, the client will have to raise an error and still cope with the lack of the feature. The error can be mitigated if the client configuration specifies required vs optional, the client can progress on the connection, but the duplicate messages will be received (behaviour since the beginning of time).

If this setting was a server configuration that is transmitted to the client, existing clients would break, but the fix is one that the client could handle automatically by creating a second connection where those subscriptions can be processed. In my mind, this is an easier paradigm to migrate code.