Fix: correctly handle peer updates while waiting to reconnect

[msgmaxim]

Pull Request

Checklist

Please conduct a thorough self-review before opening the PR.

• I am confident that the code works.
• I have updated documentation where appropriate.

Summary

In existing code it is hard to differentiate between "unknown peer" and "peer scheduled for reconnection, entry temporarily removed", so now active_connections stores ConnectionState enum with ReconnectionScheduled as a placeholder for when we don't have an actual ZMQ socket. This made it more clear what edge cases we have around reconnecting and how to best handle them, leading to the following fixes/improvements:

• when trying to send a message we no longer incorrectly log "Peer not registered" if in fact we are just reconnecting to it
• we now correctly clean up the state after a node that deregisters while we are waiting to reconnect to it (and the reconnection will be cancelled too)
• when node updates their peer info record while we are waiting to reconnect to it, it used to be possible that old state wasn't correctly cleared, but now it is done correctly

[codecov]

Codecov Report

Merging #4052 (9d7ad00) into main (d69ebb6) will increase coverage by 0%.
Report is 1 commits behind head on main.
The diff coverage is 52%.

@@          Coverage Diff          @@
##            main   #4052   +/-   ##
=====================================
  Coverage     72%     72%           
=====================================
  Files        369     369           
  Lines      59322   59301   -21     
  Branches   59322   59301   -21     
=====================================
+ Hits       42676   42678    +2     
+ Misses     14528   14503   -25     
- Partials    2118    2120    +2     

Files	Coverage Δ
engine/src/p2p/core/socket.rs	92% <ø> (-1%)	⬇️
engine/src/p2p/core.rs	80% <52%> (-2%)	⬇️

... and 13 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more