feat(vm): switch VM network datapath to eBPF bpfbridge binding

[LopatinDmitr]

Description

Integrates the new bpfbridge network binding plugin (kubevirt side: deckhouse/3p-kubevirt#99) into the virtualization module and switches VM network interfaces to it, replacing the classic tap + veth + Linux-bridge datapath used for VM networks.

Module-side changes in this PR:

• Pin 3p-kubevirt to the branch that adds the bpfbridge binding plugin (feat(vm): add bpfbridge network binding plugin 3p-kubevirt#99).
• Build the eBPF datapath object bpf_bridge.o in virt-artifact (adds clang / libbpf-devel) and ship it into virt-handler at /usr/share/network-bpf-bridge-binding/bpf_bridge.o.
• Register the bpfbridge network binding plugin in the KubeVirt CR (domainAttachmentType: tap, migration enabled).
• Build VM interfaces with binding: bpfbridge instead of Bridge.
• Add the network.deckhouse.io/tap-provision-by-dvp-supported annotation to coordinate TAP provisioning by DVP.

Why do we need it, and what problem does it solve?

The classic tap + veth + Linux-bridge wiring for VM networks adds a per-packet bridge hop and extra devices inside the pod. The bpfbridge plugin replaces it with a small eBPF (tc) L2 proxy (tc_l2_proxy) that redirects frames directly between the VM tap and the pod/CNI veth by ifindex. This gives a leaner datapath for the Main network and, importantly, makes additional ClusterNetwork interfaces work: VMs can talk over an additional network, keep it across live migration, and hotplug/hotunplug ClusterNetworks — including VMs that have only an additional network and no Main.

What is the expected result?

• VMs with a Main + additional ClusterNetwork reach each other over the additional network, before and after live migration.
• A VM with only an additional network (no Main) also gets additional-network connectivity.
• Additional ClusterNetwork interfaces can be hotplugged/hotunplugged on a running VM without reboot.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vm
type: feature
summary: "VM networks moved to an eBPF datapath: stable additional-network connectivity with lower overhead."