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

@@ -446,8 +446,8 @@ the routing table, and everything else from the database.
           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. It applies them in order after
-          the peer has left every prefix and after the held-back updates of
-          every peer whose session went down before it.
+          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
@@ -652,11 +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 after the peer has left every prefix
-  and after the held-back messages of every peer whose session went down before
-  it. It holds at most 150,000 such messages (`maxHeldBackMessages`), about 150
-  MiB. At that number it takes nothing more off its queue until it has applied
-  one of them.
+  peer's session goes down. It applies them after the peer has left every
+  prefix, once the messages held back before them are applied. It holds at most
+  150,000 such messages (`maxHeldBackMessages`), about 150 MiB. At that number
+  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.