Take every down peer out of the table in one walk (closes #225)

The prefix handler ran one PeerDown per peer, one after another. When
the sessions of several peers went down together, their walks queued up.
A returning full-table peer's messages stayed held back while the walks
ahead of its own ran, and could reach the limit of 20,000.

The table's PeersDown now takes several peers out of every prefix in one
walk. One walk runs at a time. The next one takes every peer whose
session went down since the previous one began. The doc of
maxHeldBackMessages says how long a peer's messages are held back. The
limit is now 150,000 messages, about 150 MiB. The status page shows how
many messages each handler holds back.

Model: opus-5-5

README.md

@@ -445,8 +445,9 @@ the routing table, and everything else from the database.
         - A withdrawal removes the peer's route. So does an announcement whose
           AS path is empty or holds AS 0 anywhere.
         - A peer whose BGP session goes down leaves every prefix. The handler
-          holds back the peer's later updates until the peer has left every
+          holds back the peer's later updates. It applies them in order after
-          prefix, then applies them in order.
+          the peer has left every prefix, once the updates held back before them
+          are applied.
 
         Every second it writes the changed prefix and origin AS pairs to the
         `routes` table. A write takes at most 20,000 pairs, and the rest follow
@@ -651,10 +652,10 @@ What happens at each limit:
     at most about 0.1 GiB of the Go heap.
 
 - Held-back messages: the prefix handler holds back a peer's messages after the
-  peer's session goes down. It applies them once the peer has left every prefix.
+  peer's session goes down. It applies them after the peer has left every
-  It holds at most 150,000 such messages (`maxHeldBackMessages`), about 150 MiB.
+  prefix, once the messages held back before them are applied. It holds at most
-  At that number it takes nothing more off its queue until it has applied one of
+  150,000 such messages (`maxHeldBackMessages`), about 150 MiB. At that number
-  them.
+  it takes nothing more off its queue until it has applied one of them.
 
 With `DEBUG=routewatch` the daemon logs a `System stats` line every 60 seconds
 with the goroutine count and Go memory figures.

internal/routewatch/prefixhandler.go

@@ -73,9 +73,10 @@ const (
 // at a time. The next one takes every peer whose session went down since the
 // previous one began. PeersDown lets the table's lock go about half of the
 // time, so the handler applies other peers' messages while PeersDown runs. The
-// handler holds back a down peer's later messages until the peer has left every
+// handler holds back a down peer's later messages until peerDown applies them,
-// prefix. Then the handler applies them in order, one at a time, and takes new
+// as the doc of maxHeldBackMessages describes. It applies them in order, one at
-// messages in between. It holds back at most maxHeldBackMessages messages.
+// a time, and takes new messages in between. It holds back at most
+// maxHeldBackMessages messages.
 //
 // Each flush writes the table's changes to the database. It also stores each
 // prefix the updates name with the time it was first seen.
@@ -228,8 +229,7 @@ func (h *PrefixHandler) QueueCapacity() int {
 }
 
 // HandleMessage processes a message to track prefix information. A message
-// from a peer whose session went down is held back until the peer has left
+// from a peer whose session went down is held back until peerDown applies it.
-// every prefix.
 func (h *PrefixHandler) HandleMessage(msg *ristypes.RISMessage) {
 	h.mu.Lock()
 	defer h.mu.Unlock()