Raft leader election.

If follower B promotes itself because leader A went quiet, and A was only slow, you have two leaders: split-brain (Day 5, section 1.1). Raft's leader election avoids it with terms and majorities (sections 3.2 and 3.3; Ongaro and Ousterhout, "In Search of an Understandable Consensus Algorithm", USENIX ATC 2014). Every node votes at most once per term, a candidate needs a majority of the whole cluster, and two majorities always share a node, so no term can have two leaders.

Implement RaftNode(node_id, peers, clock, rng, send, election_timeout=(0.15, 0.30), heartbeat_interval=0.05):

send(dst, msg) sends a message (a dict) to another node. The four messages, with exactly these fields:

The rules (the paper's Figure 2, election parts only):

• Higher term wins. Any message, request or reply, whose term is above yours: adopt that term, become a follower, clear voted_for and leader_id, then handle the message.
• Election timer. A follower or candidate whose election deadline has passed (now >= deadline) starts an election in tick(): term += 1, become candidate, vote for itself, send RequestVote to every peer. It wins once it holds votes from a majority of the whole cluster ((len(peers) + 1) // 2 + 1, its own vote included), counting each voter once (replies can arrive twice), and only replies of its current term count.
• Voting. Reply granted = False if the request's term is below yours. Otherwise grant it if you haven't voted this term or already voted for this same candidate, and record the vote: one vote per term, first come, first served. Every request gets a reply carrying your (possibly just updated) term.
• Leading. A new leader sets leader_id to itself and sends AppendEntries to every peer at once, then again in tick() whenever heartbeat_interval has passed since the last round.
• Heartbeats. An AppendEntries with a term below yours gets success = False (that's how an old leader learns the new term). Otherwise become (or stay) a follower of that leader, set leader_id, reset your election timer and reply success = True. A candidate that hears from a leader of its own term steps down this way.
• Resetting the timer means deadline = now + rng.uniform(lo, hi), a fresh random draw from election_timeout. Reset it at construction, when you start an election, when you grant a vote, when you accept a heartbeat, and when a higher term makes you a follower. That last reset is this model's choice, so a deposed leader doesn't start an election the moment it steps down; the paper's Figure 2 resets the timer when a node starts an election, grants a vote or hears from the current leader. Call rng.uniform nowhere else: the tests script the draws.
• Read time only through clock.now(), and don't change a message you receive (a duplicate delivers the same object again).

Cluster (Given) wires nodes together on a zero-latency network: step() advances the clock 10 ms, ticks every node in id order, then delivers every queued message and every message those trigger, in send order. It can partition({...}, {...}), heal() and pause nodes (cluster.down: a paused node neither ticks nor receives, like a long GC pause).

In JavaScript and TypeScript it's new RaftNode(nodeId, peers, clock, rng, send, { electionTimeout: [0.15, 0.3], heartbeatInterval: 0.05 }) with state, term, votedFor, leaderId (null for none), tick() and receive(src, msg); messages are plain objects with the same fields.

The chaos tests run five nodes for two simulated seconds while the scheduler delivers messages in random order, duplicates some and partitions the network (the test also splits off random two-node minorities): no term may ever have two leaders, and no node's term may go backwards.