Keep taking messages while a peer's session goes down (closes #216)

The table's PeerDown visits every prefix under the write lock, which
takes over a second on a full table. The prefix handler called it
inline, so its queue filled and the streamer dropped updates.

PeerDown now holds the lock for 10,000 prefixes at a time, then lets
the lock go for as long again. The handler runs PeerDown on a separate
goroutine, one peer at a time. The handler holds back the down peer's
later messages until that PeerDown returns. Then the handler applies
them in order, one at a time, and takes new messages in between. It
holds back at most 20,000 messages. Stop waits for all of this before
its last flush.

Model: opus-5-5

README.md

@@ -444,7 +444,9 @@ the routing table, and everything else from the database.
         - An announcement gives the peer a route to the prefix.
         - 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.
+        - 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
+          prefix, then applies them in order.
 
         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
@@ -580,8 +582,8 @@ Budget:
 - Go heap: a 2.5 GiB soft limit (`GOMEMLIMIT=2560MiB`, set in the image).
     - The routing table takes about 700 bytes per prefix and origin AS. A full
       table has about 1.4 million of these pairs, so it takes about 1 GB.
-    - The rest of the heap takes up to about 0.5 GiB. Most of it is the
-      handlers' batches and queues, described below.
+    - The rest of the heap takes up to about 0.5 GiB. Most of it is what the
+      handlers hold, described below.
     - The remaining 1 GiB is room for the garbage collector. With much less, it
       would run almost all the time.
 - SQLite: 656 MiB of page cache.
@@ -648,6 +650,12 @@ What happens at each limit:
     as above. With the batches being written, the three handlers' batches take
     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.
+  It holds at most 20,000 such messages (`maxHeldBackMessages`), about 20 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.