[Added] natsConnection_Reconnect

[levb]

Implements nats-io/nats-architecture-and-design#259

[codecov]

Codecov Report

Attention: Patch coverage is 57.14286% with 15 lines in your changes are missing coverage. Please review.

Project coverage is 68.67%. Comparing base (3f02b1d) to head (27fd5df).
Report is 1 commits behind head on main.

Files	Patch %	Lines
src/conn.c	57.14%	5 Missing and 10 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #756      +/-   ##
==========================================
- Coverage   68.72%   68.67%   -0.06%     
==========================================
  Files          39       39              
  Lines       15176    15189      +13     
  Branches     3137     3139       +2     
==========================================
+ Hits        10430    10431       +1     
- Misses       1695     1704       +9     
- Partials     3051     3054       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kozlovic]

Could you review my comment and see if we could make the changes only in the new function (no existing code would need to be changed)?

[kozlovic]

There was a reason we used a different status here. What we wanted to report as the error was the error that was given to processOpError(), not an internal one that we may encounter trying to setup the reconnect.

[levb]

right, and I think my code still does that (newErr), but in the case of a natsConnection_Reconnect failing on a to fire off doReconnect we want to return the actual failure, right? (like, out of memory for instance)

[kozlovic]

There is no need for the IFOK here since there is no change of s in lines above.

But overall, I think these changes are way more complicated than it needs to be (or I am missing something). If we want to cause a reconnect, locking the connection and and if the socket is valid, closing it should be enough, no?

Of course, verification that the connection is set in such a way that it allows for reconnection (I don't recall if there are options that would totally prevent a reconnect) before doing so, and if not, returning an error indication that reconnect() failed because the connection would not reconnect because of options setting, would be best.

[levb]

way more complicated than it needs to be (or I am missing something). If we want to cause a reconnect, locking the connection and and if the socket is valid, closing it should be enough, no?

@kozlovic you're likely right, I was modeling after the go changes that call an existing re-connect method, and I figured this to be the closest. I'll try what you suggested, in a separate branch.

[levb]

See #757