Check roles in OPEN and prevent route leaks with Only to Customer (RFC 9234)

A peer's configured role now does three more things:

- Our OPEN carries the BGP Role capability with what we are to the peer.
  A peer whose own says it is something that does not pair with that, or
  that sends two different roles, is refused with OPEN Message Error /
  Role Mismatch. A peer that says nothing is accepted unless require_role
  is set. A role on a peer in our own AS is a configuration error.
- Routes from a provider, a peer or a route server are marked Only to
  Customer on the way in if they are not already, and our routes are
  marked on the way out to a customer, a peer or a route server client.
- A marked route from a customer or route server client, or from a peer
  with someone else's mark, is a leak and is refused. No policy setting
  turns that off.

The packet crate gains the Only to Customer attribute (malformed:
treat-as-withdraw), and the Role Mismatch subcode is corrected from 8 to
11.

The status page shows whether the peer confirmed its role.

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

docs/RFCs.md

@@ -201,7 +201,20 @@ Implemented from version 24 of the draft.
 | 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 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
+https://datatracker.ietf.org/doc/html/rfc9234
+
+| Feature | Status |
+|---------|--------|
+| BGP Role capability sent for peers with a configured `role` | ✅ |
+| Role Mismatch (OPEN Message Error, subcode 11) when the peer's role does not pair with ours, or it sends differing roles | ✅ |
+| Strict mode (`require_role`) | ✅ |
+| Only to Customer attribute: parse, serialise, treat-as-withdraw when malformed | ✅ |
+| 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) |
 
 ### 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