Fix snapshot retry rewind handling (#657)

When a follower reports RECEIVING_SNAPSHOT, the leader should retry snapshot sync instead of applying the normal append failure rewind.
Rewinding next_log_idx from 1 to 0 causes the next request path to treat the peer progress as uninitialized and reset it to the leader's current next_slot,
which can make create_sync_snapshot_req validate against an impossible last_log_idx.

Keep next_log_idx aligned with the follower response and skip the rewind for RECEIVING_SNAPSHOT so snapshot retry starts from the expected peer progress.

Co-authored-by: yawzhang <yawzhang@ebay.com>
Co-authored-by: Jung-Sang Ahn <jungsang.ahn@gmail.com>

Author: 3 people

src/handle_append_entries.cxx

@@ -1345,6 +1345,10 @@ void raft_server::handle_append_entries_resp(resp_msg& resp) {
                     do_log_rewind = false;
                 } else if (appendix->extra_order_ == resp_appendix::RECEIVING_SNAPSHOT) {
                     p->set_snapshot_sync_is_needed(true);
+                    if (resp.get_next_idx() > 0) {
+                        p->set_next_log_idx(resp.get_next_idx());
+                    }
+                    do_log_rewind = false;
                     p_in("peer %d was in snapshot sync mode, re-sending a snapshot. "
                          "peers next log idx: %" PRIu64 ", resp next idx: %" PRIu64,
                          p->get_id(), prev_next_log, resp.get_next_idx());

tests/asio/custom_quorum_test.cxx

@@ -1417,6 +1417,7 @@ int full_consensus_with_snapshot_transfer_test() {
     restart_params.with_election_timeout_upper(RaftAsioPkg::HEARTBEAT_MS * 4);
     restart_params.with_reserved_log_items(5);
     restart_params.with_snapshot_enabled(10);
+    restart_params.with_max_append_size(5);
     restart_params.with_client_req_timeout(10000);
     restart_params.return_method_ = raft_params::async_handler;
     restart_params.use_full_consensus_among_healthy_members_ = true;