Why or why not use RequestVote RPC as heartbeat in Raft implementation?

Question

As introduced in the paper, we use empty AppendEntries RPC for heartbeat. Then how about the RequestVote RPC? When FOLLOWER or CANDIDATE receives RequestVote RPC call, is it suppose to reset the election timeout as well? Why or why not to do so?
One benefit in my mind is that when RequestVote RPC call also treated as heartbeat, we can potentially prevent the multiple candidates condition. Since multiple candidates may split votes and take longer time in the election stage. By using that as heartbeat, the RequestVote RPC calls from one candidate will reset the election timer so that other live peers are less likely to timeout and become a candidate as well.

Answer 1

Well, there's probably not anything inherently unsafe about it. But the problem is nodes that can't win an election can still start one. So, if a node that can't win starts an election and requests votes from all the other nodes, resetting their timers would block the election. And since the can't-win candidate started its timer first, it would likely also timeout and start another election first, thus blocking the cluster again, and another election, and so on.

Of course, the fix for this could be to only reset election timeouts when a vote is cast. This could be safe. After all, election timeouts are randomized anyways. But the question is whether it's effective. It wouldn't prevent split votes since it doesn't stop multiple nodes from requesting votes concurrently, and during split votes it would only make the election take that much longer. I suspect the pre-vote protocol is much more efficient for that reason and probably avoids split votes as well as they can be avoided.