feat: VPCS kernel datapath

A VPCS node's single adapter anchors on a persistent TAP the server
creates (tap create + set_owner via uBridge) and the vpcs process
attaches to by name: -e -d <gp{id8}e0p0> -n, the same
server-creates/guest-attaches shape as QEMU's netdev. -n (a vpcs fork
feature) keeps the guest's ip command from ifconfig'ing the anchor on
the host; the vpcs build is probed once per binary identity
(vpcs_tap capability, usage scan) and gates kernel links together
with ubridge_tap — anything else keeps the node on the relay (the
legacy local UDP tunnel on a stock binary, an AF_PACKET endpoint on
the anchor with a capable one).

VPCSVM takes KernelDatapathMixin: _connect_nio dispatches kernel
(enslave into the per-link bridge) / relay-on-anchor / legacy,
captures pick capture start_kernel vs the bridge engine, stop runs
under an execute lock and terminates the process before deleting the
anchor TAPs (a held device refuses deletion), and the duplicate-port
guard backstops the controller's. The NIO routes accept nio_bridge
and write suspend back on update.

_delete_anchor_taps verifies each tap is gone from sysfs and retries
a bounded three times: a holder can release its fd a moment after its
process was reaped (vpcs's daemon parent kills its console child and
exits first), so the unconditional delete raced EBUSY and leaked the
anchor intermittently.

The vpcs side needs IFNAMSIZ (16) instead of its own IFNAMESIZ (12)
for the -d name buffer — anchor names are 14 chars and truncated to a
nonexistent device, which TUNSETIFF then tries to create without
CAP_NET_ADMIN (fixed in the vpcs fork).

e2e (tests/e2e/test_vpcs_kernel_datapath.py): kernel and relay
scenarios green against the real binary — real ICMP both ways, §E.1/§
E.2 on the anchors, delay/suspend/capture, link delete/re-create,
node stop/restart self-heal, zero leftovers; the relay control passes
with both the fork binary and a stock one.

gns3server/utils/kernel_anchor.py

@@ -22,10 +22,11 @@ deterministically: ``g<type>{node_id[:8]}e{adapter}p{port}`` — ``gv`` for a
 Docker veth host end, ``gq`` for a QEMU TAP, ``gi`` for an IOU port TAP,
 ``gd`` for a Dynamips port TAP, ``gx`` for an IOL runner container's port
 TAP (a Docker node whose guest leg is unix sockets, so its anchor is a TAP
-like IOU's, not a veth). The prefixes keep anchors out of the ``gns3``
-bridge/TAP name space and name-collision-free on a host; the 8 hex chars of
-the node id plus adapter/port keep every name unique and within IFNAMSIZ
-(15).
+like IOU's, not a veth), ``gp`` for a VPCS TAP (the vpcs process attaches to
+the pre-created anchor with ``-e -d`` instead of speaking UDP). The
+prefixes keep anchors out of the ``gns3`` bridge/TAP name space and
+name-collision-free on a host; the 8 hex chars of the node id plus
+adapter/port keep every name unique and within IFNAMSIZ (15).
 
 The compute classes create their anchors with these helpers (single source
 of truth), and so does the controller when a switch link has to name the
@@ -46,6 +47,7 @@ ANCHOR_PREFIX = {
     "qemu": "gq",
     "iou": "gi",
     "dynamips": "gd",
+    "vpcs": "gp",
 }