Pass learned routes on to peers, with marks and control communities

What was to be scripted is configuration, done natively:

- import { add_communities, add_large_communities, remove_communities,
  local_pref }: every route taken from a peer is marked (where it was
  learned, say), with nobody else's word for our marks taken, and given
  its preference, which selection goes by.
- export { add_communities, add_large_communities, remove_communities,
  as_path_prepend, learned_routes }, for a peer or for all that have none
  of their own.
- control_communities: the communities by which routes say which peers
  they are passed on to, as exchanges' route servers have them (0:P, L:P,
  0:L, and the large forms L:0:P, L:1:P, L:0:0), taken off as the route
  goes on.

And what the last of these is for: with export.learned_routes a peer is
told the best route of every prefix the others announced. The rules are
BGP's and cannot be turned off: not back where it came from, not to a
peer whose AS is on the path, not between two internal peers, not past
NO_EXPORT or NO_ADVERTISE; our AS on the path and ourselves as next hop
to another network, LOCAL_PREF to our own; to a route server's client
the path, MED and next hop as they came (RFC 7947). Which routes go where
follows from the roles of RFC 9234: a route that came down or across goes
on down only, so that with roles on every peer this makes us transit for
our customers and nothing else. A peer without a role is told everything,
and the daemon says so at startup.

Each session follows the table's best routes with a reader and keeps the
prefixes it has announced, so that it can withdraw them. Routes that go
out alike go in one UPDATE: changes are gathered for 50 ms first, and a
table that is given out anew is gathered whole (at most four sessions at
a time; it is tens of megabytes). For that to work the table's journal
had to give out together what was written together: every change now
carries a time on a table-wide clock, a reader's pass reads every shard
up to one time, no further than the changes that are complete in every
shard, and a resync takes its places in the journals as of one time.

One peer sending 1.23 M routes over a session, another told of them:
in our table after 0.47 s, all heard after 2.1 s, four routes an UPDATE.
The lab has a phase, transit: FRR as our customer and BIRD as our
provider, routes each way with the right paths and marks, one kept back
by a community, and pings between their networks through us.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/RFCs.md

@@ -37,7 +37,10 @@ The base protocol specification.
 | §9.1.2.1 | Next hops resolved through other routes | ❌ (only next hops that are neighbors count as reachable) |
 | §9 | Adj-RIB-In (per-peer table of received routes) | ✅ |
 | §9 | Locally originated routes, advertised to all established peers | ✅ |
-| §9 | Loc-RIB / Adj-RIB-Out for routes learned from peers (re-advertisement) | ❌ |
+| §9 | Loc-RIB / Adj-RIB-Out: the best route of each prefix passed on to peers (`export.learned_routes`), with our AS on the path and ourselves as next hop; MED and LOCAL_PREF not sent to other networks; LOCAL_PREF to our own (§5.1.4, §5.1.5, §9.1.3) | ✅ |
+| §9.2.1 | No route learned from one internal peer passed to another (no route reflection) | ✅ |
+| §9.1.3 | A route not sent to a peer whose AS is on its path | ✅ |
+| §5 | Unknown optional transitive attributes passed on with the Partial bit set; non-transitive ones dropped | ✅ |
 | §9.2 | Hold timer reset on any received message (not only KEEPALIVE) | ✅ |
 
 ---
@@ -148,6 +151,8 @@ https://datatracker.ietf.org/doc/html/rfc1997
 |---------|--------|
 | `COMMUNITIES` path attribute (parse, serialise) | ✅ |
 | Attach to locally originated routes | ✅ |
+| NO_EXPORT, NO_EXPORT_SUBCONFED and NO_ADVERTISE honoured when learned routes are passed on | ✅ |
+| Communities put on and taken off routes by configuration (`import` and `export`) | ✅ |
 
 ### RFC 4360 — BGP Extended Communities Attribute
 https://datatracker.ietf.org/doc/html/rfc4360
@@ -219,6 +224,15 @@ Implemented from version 24 of the draft.
 | Paths with an AS_SET invalid | ✅ |
 | Verification on export | ❌ (learned routes are not exported yet) |
 
+### RFC 7947 — Internet Exchange BGP Route Server
+https://datatracker.ietf.org/doc/html/rfc7947
+
+| Feature | Status |
+|---------|--------|
+| §2.2.1 / §2.2.2: to a `ROUTE_SERVER_CLIENT` the path is not prepended and the next hop and MED are left as they came | ✅ |
+| §2.2.2.2 / §4.6: communities by which a client says which other clients are told of its route (`control_communities`) | ✅ |
+| Per-client best path selection (a different best route for each client) | ❌ (every client is told the one best route) |
+
 ### RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
 https://datatracker.ietf.org/doc/html/rfc9234
 
@@ -231,7 +245,7 @@ https://datatracker.ietf.org/doc/html/rfc9234
 | Ingress: marked routes from customers, route server clients and (unless marked by the peer itself) peers refused | ✅ |
 | Ingress: routes from providers, peers and route servers marked | ✅ |
 | Egress: originated routes to customers, peers and route server clients marked | ✅ |
-| Egress: marked routes not sent to providers, peers or route servers | ❌ (learned routes are not exported yet) |
+| Egress: marked routes not sent to providers, peers or route servers | ✅ |
 
 ### RFC 8210 — The RPKI to Router Protocol, Version 1 (RFC 6810, version 0; draft-ietf-sidrops-8210bis, version 2)
 https://datatracker.ietf.org/doc/html/rfc8210