…e strict (#10155)

Staged on top of #10122, which strengthened the types used for BGP peers
in the external API.

* Always represent unnumbered peers as a `NULL` address
* Add `CHECK` constraints that prevent storing the addresses `0.0.0.0`
or `::` to ensure we don't have any leftover sentinel values
* For the three tables that required the address to be non-NULL because
it was part of a composite primary key, add a new synthetic `id` primary
key (a random UUID)

The database migrations are similar in spirit to #9976: while we're not
correcting mismatches between diesel and CRDB here, we are introducing
migrations that _could_ fail if real databases have data we don't expect
(e.g., an address of `0.0.0.0` in the table where we expect unnumbered
peers to be represented as NULL). The tactic I went with in the
migration is:

* If there's only one unnumbered peer (treating NULL, 0.0.0.0, :: all as
possibilities), convert it to `NULL`.
* If there are multiple, keep one (preferring `NULL` then `0.0.0.0`) and
delete the rest. This shouldn't delete anything unless someone has some
already-invalid-at-runtime data.

There's a data migration test that should cover a sample of each kind of
possibly-invalid input and confirm the above behavior.

One other thing that snuck in here is a bugfix for #10151.