[Bug]: wrong response of fast_round if there are two leaders

[iGxnon]

Description about the bug

In #582, the test case will failed, we should fixed it.

/// FIXME: two leader
/// TODO: fix in subsequence PR
#[traced_test]
#[tokio::test]
#[should_panic]
async fn test_unary_fast_round_with_two_leader() {
    let connects = init_mocked_connects(5, |id, conn| {
        conn.expect_propose().return_once(move |_req, _timeout| {
            let resp = match id {
                // The execution result has been returned, indicating that server(0) has also recorded the command.
                0 => ProposeResponse::new_result::<TestCommand>(&Ok(TestCommandResult::new(
                    vec![1],
                    vec![1],
                ))),
                // imagine that server(1) is the new leader
                1 => ProposeResponse::new_result::<TestCommand>(&Ok(TestCommandResult::new(
                    vec![2],
                    vec![2],
                ))),
                2 | 3 => ProposeResponse::new_empty(),
                4 => return Err(CurpError::key_conflict()),
                _ => unreachable!("there are only 3 nodes"),
            };
            Ok(tonic::Response::new(resp))
        });
    });
    // old local leader(0), term 1
    let unary = Unary::<TestCommand>::new(connects, None, Some((0, 1)));
    let res = unary
        .fast_round(ProposeId(0, 0), &TestCommand::default())
        .await
        .unwrap()
        .unwrap();
    // quorum: server(0, 1, 2, 3)
    assert_eq!(res, TestCommandResult::new(vec![2], vec![2]));
}

Version

0.6.0 (Default)

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[iGxnon]

By introducing leader_id and term in ProposeRequest, we may fix that bug.