ProtocolV2: modify handle_existing_connection logic

ProtocolV2: modify handle_existing_connection logic

Problem:
When a monitor daemon (e.g., mon.c) is killed and restarts, its
attempt to re-establish a session with a peer (mon.a) is incorrectly
rejected. This happens because mon.a retains stale connection state,
including a higher peer_global_seq, from the previous session.

When the newly restarted mon.c sends a ClientIdentFrame with a fresh
client_cookie and a low global_seq (e.g., 1), mon.a compares this
against the old connection’s peer_global_seq (e.g., 61) and mistakenly
concludes that the connection is stale. As a result, mon.a terminates
the incoming connection from mon.c, delaying session recovery and
triggering a transient MON_NETSPLIT warning. The connection is only
recovered once mon.a's backoff timer expires and it initiates a new
connection to mon.c.

Solution:
Reorder the logic in handle_existing_connection so that the check for
client_cookie mismatch is performed before the global_seq comparison.
This leverages the existing code path that handles session resets and
restarts when a peer has generated a new client_cookie (e.g., after a
daemon restart). By bumping this condition earlier, we avoid
incorrectly rejecting valid new connections as "stale" and instead
allow proper session negotiation to proceed. This change prevents
unnecessary connection drops and eliminates the transient MON_NETSPLIT
in such restart scenarios.

Fixes: https://tracker.ceph.com/issues/71344
Signed-off-by: Kamoltat Sirivadhna <ksirivad@redhat.com>