Receipt of REPLCONF VERSION reply should be triggered by event

[enjoy-binbin]

This add the missing return when repl_state change to RECEIVE_VERSION_REPLY,
this way we won’t be blocked if the primary doesn’t reply with REPLCONF
VERSION.

In practice i guess this is no likely to block in this context, reading
small responses are are likely to be received in one packet, so this
is just a cleanup (consistent with the previous state machine processing).

Also update the state machine diagram to mention the VERSION reply.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.55%. Comparing base (3d0c834) to head (fe8b010).
Report is 1 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1320      +/-   ##
============================================
- Coverage     70.71%   70.55%   -0.17%     
============================================
  Files           115      115              
  Lines         63159    63160       +1     
============================================
- Hits          44666    44562     -104     
- Misses        18493    18598     +105     

Files with missing lines	Coverage Δ
src/replication.c	87.14% <100.00%> (-0.17%)	⬇️

... and 11 files with indirect coverage changes

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[zuiderkwast]

So we have to wait for the read handler to run again for each of the replies?

[zuiderkwast]

There's a state machine diagram in a comment in this file too. Maybe we should update it too.

 * Replica state machine * 
 ┌───────────────────┐     
 │RECEIVE_PING_REPLY │     
 └────────┬──────────┘     
          │+PONG           
 ┌────────▼──────────┐     
 │SEND_HANDSHAKE     │     
 └────────┬──────────┘     
          │                
 ┌────────▼──────────┐     
 │RECEIVE_AUTH_REPLY │     
 └────────┬──────────┘     
          │+OK             
 ┌────────▼──────────┐     
 │RECEIVE_PORT_REPLY │     
 └────────┬──────────┘     
          │+OK             
 ┌────────▼──────────┐     
 │RECEIVE_IP_REPLY   │     
 └────────┬──────────┘     
          │                
          │                
          │                
          │                
          │+OK             
 ┌────────▼──────────┐     
 │RECEIVE_CAPA_REPLY │     
 └────────┬──────────┘     
          │                
 ┌────────▼───┐            
 │SEND_PSYNC  │            
 └─┬──────────┘            

[enjoy-binbin]

So we have to wait for the read handler to run again for each of the replies?

yean, look like the answer is yes. (in happy path we don't have to since we pipeline the write, and we can read the reply without any block)

[zuiderkwast]

So we have to wait for the read handler to run again for each of the replies?

yean, look like the answer is yes. (in happy path we don't have to since we pipeline the write, and we can read the reply without any block)

But we return after each read state. To read the next reply, we wait for read handler.

[zuiderkwast]

Beautiful

[enjoy-binbin]

But we return after each read state. To read the next reply, we wait for read handler.

yes, what i want to say is the "ideally path". In current code, we do need to wait for the next read handler.

[zuiderkwast]

But we return after each read state. To read the next reply, we wait for read handler.

yes, what i want to say is the "ideally path". In current code, we do need to wait for the next read handler.

OK, if sync is slow to start, we can optimize it later. I don't think it's too slow.