Peer classes, so one peer may initiate to others while the rest stay isolated

[catinspace-au]

CULVERT_CLIENT_ISOLATION is one global boolean, so a deployment gets either
"no peer may reach another" or "every peer may reach every other". We want a
third thing: an edge fleet where the appliances stay isolated from each other,
and ONE admin peer may initiate to them for remote administration.

CULVERT_DOWNSTREAM_ADMIN_CIDRS is nearly it, but it is aimed at a source
arriving off a tunnel interface. In setup_routing_control the client-to-client
verdict is installed first, over every in/out pair of tunnel interfaces, so a
packet from an admin that is ITSELF a peer is dropped before the admin ACCEPT is
reached (scripts/lib/network.py). Our admin dials in exactly the way an
appliance does, so that is the case we have. The NAT RETURN beside it reads the
same way, since it exists to keep a peer's real tunnel source on a reply to an
admin that is not a peer.

The other half is addressing. allocate_peer_ip hands out the next free address
in the WireGuard /24 and nothing can ask for a particular one, so even with a
rule to write there is no admin range to write it against.

What we are after, roughly:

• a class per client, chosen at generate-client time and remembered, so a
  restart does not forget which peer is which
• isolation kept between peers of the appliance class
• a one-way exception: the admin class may initiate to a peer, and appliance
  peers get ESTABLISHED,RELATED back and nothing more
• a per-class address range would help, because then the exception is a CIDR
  rule rather than a per-peer one
• revoke-client already covers taking the admin peer away, so nothing new
  is needed there

Happy to take a narrower shape if you would rather. A per-class address range
plus one ACCEPT above the isolation verdict would be enough for us.

Done when a peer issued in the admin class can open a connection to an appliance
peer's tunnel address while two appliance peers still cannot reach each other.