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 lets the lock go after every 10,000 prefixes. The handler
runs it on a separate goroutine, one peer at a time. It holds back the
down peer's later messages until that PeerDown returns. Then it 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.