Implement KNE Packet Bridge daemon and CLI subcommand

[kraney]

Summary

Adds the KNE Packet Bridge: a daemon that carries raw Layer 2 Ethernet frames
between network segments over a gRPC stream, so that a KNE topology can be wired to
something that is not in the same cluster — another KNE cluster, a workstation veth,
or a process running outside Kubernetes entirely.

A FORWARD node declares the wires it terminates and KNE derives the daemon
invocations. The topology never names a flag, a port, or a Kubernetes object.

The contract

proto/forward.proto already described this model — a list of wires, each with an a
and a z endpoint — but nothing implemented it. This PR implements it, including the
RemoteNode endpoint that was declared and unreachable.

The endpoint written as an interface is always the declaring node:

Wire	Meaning
a: { interface }, z: { local_node }	this node dials a peer in the topology
a: { interface }, z: { remote_node }	this node dials an address outside it
z: { interface }, no a	this node listens; the client is external

So a node that a Borg job attaches to is written as:

nodes: {
  name: "bridge-server"
  vendor: FORWARD
  config: {
    vendor_data: {
      [type.googleapis.com/forward.ForwardConfig] {
        wires: { z: { interface: { name: "eth1" } } }
      }
    }
  }
  services: { key: 50058 value: { name: "wire" inside: 50058 type: NODE_PORT } }
}

No image, no CLI flags, no Service names. Two consequences fall out of the model:

• Peer resolution. Naming a peer with local_node requires that name to resolve,
  and nothing created a Service under a node's own name. Every FORWARD node now gets
  a headless Service named after it. It declares no ports — a headless Service needs
  only a selector to publish A records, and ports would place it in the map kne show
  reports and collide with the wire port a topology may already expose. It carries the
  pod label so the node's existing teardown removes it.
• Mode per process. The daemon runs either as a server or as a client, so a node
  that both serves and dials gets one container per role, named <node>-<role>. A node
  needing only one keeps the plain node name.

Changes

Bridge daemon and client (bridge/, cmd/bridge/)
Bidirectional streaming of raw frames over the existing Wire service, with a
per-interface demux so one server can serve many wires on one port. kne bridge server
and kne bridge client, with interface binding, reconnect, and optional ALTS transport
credentials for DirectPath on GCE.

Wire planning (topo/node/forward/)
ForwardConfig is translated into daemon invocations and containers, plus the headless
peer Service described above. The default image points at the published bridge image, so
topologies no longer carry an image: line.

Service exposure (proto/topo.proto, topo/node/, topo/topo.go)
Service.Type gains LOAD_BALANCER, NODE_PORT and CLUSTER_IP, with one Kubernetes
Service created per requested type. Service.external_ipv6 states that a service should
be reachable over IPv6 from outside the cluster; on a single-stack IPv4 cluster KNE
satisfies that with a host-network socat DaemonSet, and on a dual-stack cluster it may
become a no-op. outside_ip is now documented as populated only for LOAD_BALANCER.

Build and release (Makefile, deploy/bridge/, cloudbuild/, cmd/release/)
A Dockerfile whose entrypoint is kne bridge, make targets for local kind testing, and
kne release bridge driving a Cloud Build pipeline. The bridge image is the kne binary,
so it has no version of its own: releasing it tags KNE as a whole and labels the image
with that version, rather than minting a separate series.

Testing

Unit tests for bridge/, cmd/bridge/, the wire planner and peer Service in
topo/node/forward/, and the service-type handling in topo/. The planner tests cover
each endpoint shape, both malformed-wire cases, and the mixed server-plus-client node.

Verified on kind: kne deploy, then kne create of examples/bridge/paired-bridge.pb.txt,
then ping between the two hosts, which have no meshnet link and reach each other only
across the bridge. That exercises wire planning, peer resolution through the headless
Service, stream establishment, and bidirectional forwarding.

Also verified on kind with external_ipv6: true set on the service: the socat DaemonSet
is admitted, which exercises the apps/daemonsets grant added to the podrunner
ClusterRole, and its pod reaches Running, which exercises the explicit non-root UID the
container needs in order for the kubelet to accept it.

Not yet exercised on a cluster: multi-container FORWARD nodes and remote_node
endpoints. Both are covered by unit tests only.

Notes for reviewers

• Service.v6_host_proxy was renamed to Service.external_ipv6. This is a breaking proto
  change, made deliberately while nothing depends on the field, because the old name
  described the mechanism rather than the intent.
• deploy/ubuntu/serviceaccount.yaml is reindented throughout. super-linter runs prettier
  over every file a PR touches rather than only the changed lines, and this file did not
  previously indent block sequences under their mapping key. The parsed documents are
  unchanged.
• x/wire/ contains an earlier, unfinished implementation of the same Wire service. It
  is untouched here and nothing imports it; retiring it is left to a follow-up.

[manizzzz]

Thanks for the changes.

[manizzzz]

Thanks for the super thorough fixes on the and new test suite all look great!

Holding LGTM for three small issues in the new diff before we merge:

1. bridge/bridge.go (ReadPacket / WritePacket): retry unix.EINTR inside the s.rc.Read / s.rc.Write callbacks (RawConn doesn't ignore EINTR, so
   Go's SIGURG preemption will cause readLoop to tear down the demux).
2. bridge/bridge.go (Server.Transmit): wait for the egress goroutine after demux.unsubscribe(pktChan) in the defer so stream.Send cannot race
   with Transmit returning.
3. topo/node/forward/forward.go (CreatePod): preserve pb.Config.Args when ForwardConfig.wires is used so flags like --alts aren't dropped.

Left a few optional/non-blocking comments on forward.go and node.go as well. Once (1)–(3) are in, this is good to LGTM!

[bstoll]

I didn't verify this but if GSO/TSO are enabled on the veth do TCP and UDP packets get forwarded with valid checksums? I think the way this reads packets they will forward with invalid checksums unless hardware offloads are disabled.