feat: Decide internet egress per network, not per node

[scotwells]

Whether a tenant network reaches the internet is decided per node today. One list of translating shards is set at install time, so every network on that node routes toward it and a network that should have no outbound path gets one anyway.

This makes the decision per network: a network reaches the internet when its attachment declares it, reaches nothing when it does not, and loses an already installed route when the declaration goes away.

The declaration names no shard, so the list a node already holds decides where its networks leave, and each attachment decides whether.

API

// One attachment's stanza in a node's CNI config. Two answers.

// reaches the internet, through the shard this node's configuration names
{ "type": "galactic-bgp", "vpcattachment": "web-01", "egress": { "internet": { "mode": "Enabled" } } }

// reaches nothing outside the platform, and withdraws a route that is there
{ "type": "galactic-bgp", "vpcattachment": "web-01" }

Important

An attachment whose stanza carries no declaration gets no egress route, and one that declares egress on a node naming no shard fails its attach. Every conflist the lab renders now carries the declaration, and a deployment rolling this out has to render it before nodes can rely on the node-wide list alone.

Test plan

• A network with no egress declared installs no outbound route, on a node that has shards
• A network that loses its declaration has both its routes withdrawn
• A network that declares egress on a node naming no shard fails its attach with a reason
• Every lab tenant keeps the egress it has today

Related to datum-cloud/network-services-operator#475