Verify AS paths with ASPAs, over RTR version 2

Origin validation says who may originate a prefix and nothing about the
rest of the path: it does not catch a route leak, nor a hijack that keeps
the right origin at the end of a made-up path. ASPAs, in which a network
lists its providers, do.

bgp-rpki:
- aspa: the ASPAs and the upstream and downstream verification procedures
  of draft-ietf-sidrops-aspa-verification-24, tested against the draft's
  wording as written.
- rtr: protocol version 2 (draft-ietf-sidrops-8210bis-23) with the ASPA
  PDU and the new error codes.
- client: asks for version 2 and falls back to whatever older version the
  cache speaks; keeps ASPAs with the VRPs, applied whole or not at all;
  publishes which customers' ASPAs changed; tells the cache why it is
  being left (Error Report); does not ask one version's serial of another.

Server:
- A peer has a role (provider, customer, peer, route server, route server
  client), which decides how its paths are verified. Without one they are
  not.
- A route whose path is invalid is refused ("ASPA invalid") and held, like
  one with an invalid origin; accept_aspa_invalid exempts a peer.
- When ASPAs change, routes in the table whose path has a changed customer
  on it are verified again, and held routes are released when they pass
  both checks.
- The revalidator finds a route's peer by index instead of searching a
  list for every route.

The status page and API show each peer's role, each route's path validity,
the number of ASPAs and the RTR version in use; bgp_rpki_aspas is on
/metricz.

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

docs/RFCs.md

@@ -187,14 +187,35 @@ https://datatracker.ietf.org/doc/html/rfc6811
 | Validation of routes from internal peers and of originated routes | ❌ |
 | Validity as a step of route selection (RFC 8097 communities) | ❌ |
 
-### RFC 8210 — The RPKI to Router Protocol, Version 1 (and RFC 6810, version 0)
+### draft-ietf-sidrops-aspa-verification — BGP AS_PATH Verification Based on ASPA
+https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/
+
+Implemented from version 24 of the draft.
+
+| Feature | Status |
+|---------|--------|
+| Upstream verification (routes from customers, peers, route servers and route server clients) | ✅ |
+| Downstream verification (routes from providers) | ✅ |
+| Per-peer role (`role`); paths of peers without one are not verified | ✅ |
+| Invalid paths refused, per peer (`accept_aspa_invalid` to take them) | ✅ |
+| Routes revalidated when the ASPAs change, in both directions | ✅ |
+| Paths with an AS_SET invalid | ✅ |
+| Verification on export | ❌ (learned routes are not exported yet) |
+| Roles negotiated in OPEN, Only-to-Customer attribute (RFC 9234) | ❌ |
+
+### 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
 
+Version 2 is implemented from version 23 of the draft.
+
 | Feature | Status |
 |---------|--------|
 | Reset and serial queries, notifies, cache reset, incremental updates | ✅ |
 | Refresh, retry and expire intervals; data dropped when it expires | ✅ |
-| Fallback to version 0; several caches with failover | ✅ |
+| Version 2, with fallback to 1 and 0; several caches with failover | ✅ |
+| ASPA PDU (version 2) | ✅ |
+| Error Reports sent to the cache | ✅ |
+| Version 2's ordering of PDUs enforced on what a cache sends | ❌ (any order is taken) |
 | Transport over plain TCP | ✅ |
 | Transport over SSH, TLS, TCP-MD5 or TCP-AO | ❌ |
 | Router keys (BGPsec) | 🟡 read and ignored |