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>

testdata/server.textpb

@@ -22,6 +22,10 @@ peers {
     # Take several routes for a prefix from this peer, if it offers to send
     # them (ADD-PATH). Also ADD_PATH_SEND and ADD_PATH_BOTH. Off by default.
     add_path: ADD_PATH_RECEIVE
+    # What the peer is to us: PROVIDER, CUSTOMER, PEER, ROUTE_SERVER or
+    # ROUTE_SERVER_CLIENT. With it, and a validator that has ASPAs, the AS
+    # paths of the peer's routes are verified, and leaked routes refused.
+    # role: PEER
     # Which of the peer's routes are taken. Without this block the general
     # checks still apply: no private or reserved prefixes or AS numbers,
     # nothing longer than /24 or /48, no default route, and a path that
@@ -53,8 +57,9 @@ originate {
     large_communities: "65000:1:2"
 }
 
-# Route origin validation: refuse routes whose origin AS is not the one the
-# holder of the addresses authorised. Point it at a validator's RTR server.
+# Validation with the RPKI: refuse routes whose origin AS is not the one the
+# holder of the addresses authorised, and, from peers with a role, routes
+# whose AS path is a leak. Point it at a validator's RTR server.
 # rpki { caches { address: "127.0.0.1" port: 3323 } }
 
 # Read-only status page, JSON API and metrics. It has no authentication: