Code health after review: docs, metrics, structure, one more fuzz target

What the code-health review found, and what a fuzz target written for it
found in its first seconds.

- A set of attributes with the same attribute twice is refused by the
  routing table. Its readers (the selection key, the path, the next hop)
  could each take a different one of the two. The decoder never lets one
  through; the new fuzz target `attrs` found that the table would.
- bgp_peer_up{peer}, to alert on a peer going away, and bgp_build_info.
  Every metric is there from the first scrape. Alerts for a peer down,
  hijack attempts and kernel errors are in the README.
- `bgp --check config` validates a configuration without starting, and
  `--version` says which build it is. CI runs the first on the example
  configuration, which a test now also parses with its commented fields
  put in; the example had to learn about the next hop check.
- Path attributes have a module of their own, packet::attributes,
  re-exported from packet::message as before.
- policy::From, which shadowed the trait, is RouteSource. The server's
  connection, dialer and fsm modules are private. Logging arguments live
  in the binary; the server library no longer depends on clap.
- One is_unicast_link_local (the standard library's) instead of two of
  our own; SelectionKey::origin(); one place where an Import is made.
- READMEs say what the daemon does today rather than what it did not do
  a year ago. Documentation links are checked in CI. Unused dependencies
  and bgp_web::serve are gone; the Docker build is --locked and does not
  ship the fuzz corpus.

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

README.md

@@ -1,43 +1,54 @@
-# BGP
+# Ferrix BGP
 
-The `bgp` crate is an implementation of the Border Gateway Protocol, which is used to exchange routing and control plane information between Autonomous Systems.
+An implementation of the Border Gateway Protocol, which is used to exchange routing and control plane information between Autonomous Systems.
 
 The aim of this project is to provide a modern, high performance, secure, programmatic and customizable software package that can be useful to network operators, researchers, and people interested in Internet.
 
-## Current status.
+## Current status
 
-The project is currently being rewritten from scratch to be more modular and maintainable, as well as to fix deeper issues with the previous implementation.
+The daemon holds sessions with configured peers, takes their routes through an import policy, validates them against the RPKI (route origin validation and ASPA), picks the best route for each prefix and, on Linux, installs it in the kernel. It announces the routes it originates. It does not yet pass routes learned from one peer on to another.
 
-⚠️ Warning: This is currently a work in progress and not ready for use.
+- [`bin/bgp/README.md`](bin/bgp/README.md): what the daemon does, how to configure and run it, and how it is tested against FRR, BIRD and Routinator.
+- [`docs/RFCs.md`](docs/RFCs.md): which parts of which RFCs are implemented.
+- [`crates/server/proto/config.proto`](crates/server/proto/config.proto): the configuration, field by field.
 
-### 🛣️ Roadmap to v1.0
+It has not yet run in a production network.
 
-We aim for the 1.0 release to be functional and stable to operate peering sessions, and to install routes in the Linux Kernel.
+### Not there yet
 
-- ☐ Implement basic parsers for the fundamental types required
-  - ✅ Path Attributes from RFC4271
-  - ✅ Open message
-    - ✅ Capabilities from RFC4271
-  - ✅ Update message
-  - ☐ Notification message
-- ✅ Implement scaffolding required to start and configure a server
-- ✅ Implement connection logic to establish sessions with peers (passive and active)
-- ✅ Routes originated from the configuration, with communities, announced to all peers
-- ✅ Read-only HTTP API, status page and Prometheus metrics
-- ☐ Implement an efficient data structure for storing prefixes (e.g. Poptrie)
-- ☐ Filtering for peer RIB in / out
-- ☐ Main / auxiliary RIBs for exchanging routes between peers
+- Announcing learned routes to other peers, and an export policy for it
+- TCP-AO / TCP MD5 and GTSM
+- Graceful restart, BFD, changing the configuration without a restart
+- Next hops that are not directly connected
+
+### Layout
+
+| Crate | What is in it |
+|-------|---------------|
+| `crates/primitives` | Prefixes, address families, parsing helpers |
+| `crates/packet` | The wire format: messages, attributes, capabilities |
+| `crates/rib` | The routing table, best route selection, the journal of changes |
+| `crates/rpki` | The RTR client; origin validation and ASPA path verification |
+| `crates/fib` | The best routes in the Linux kernel, over netlink |
+| `crates/server` | Sessions, the state machine, policy, configuration |
+| `crates/web` | The status page, HTTP API and metrics |
+| `bin/bgp` | The daemon |
 
 ## Development
 
-CI runs these three on every push, and fails on any warning:
+CI runs these on every push, and fails on any warning:
 
 ```
 cargo fmt --all -- --check
 cargo clippy --workspace --all-targets -- -D warnings
 cargo test --workspace
+RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items
 ```
 
+It also runs the tests that need a real Linux kernel
+(`scripts/kernel-tests.sh`) and the lab with FRR, BIRD and Routinator
+(`scripts/interop/lab.sh`); `scripts/linux-vm.sh` runs either from macOS.
+
 Lints are configured once, under `[workspace.lints]` in the root `Cargo.toml`.
 `unsafe` code is forbidden throughout.