confd: allow both ends of a veth pair to be assigned to containers

Previously at least one end of a veth pair had to remain in the host
namespace, because that end created and destroyed the pair.  Assigning
both ends to containers left no one to create it.

Select a deterministic primary end so exactly one side creates the pair.
When the primary is itself a container interface, create the pair in the
host namespace before the container starts; CNI host-device then moves
each end into its container.  Teardown is deferred to the container
removal script so the pair does not linger and block re-creation.

Drop the now-obsolete limitation notes from the documentation and YANG,
and add a regression test connecting two containers over a veth pair.

Fixes: #941

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

doc/ChangeLog.md

@@ -30,6 +30,8 @@ All notable changes to the project are documented in this file.
 
 ### Fixes
 
+- Fix #941: a VETH pair can now connect two containers directly, with both
+  ends assigned to containers.
 - Enabling IP masquerading in the firewall no longer enables IP forwarding on
   all interfaces.  This has been an issue ever since the firewall support was
   introduced in v25.10.0

doc/container.md

@@ -668,11 +668,9 @@ set:
 
 For an example of both, see the next section.
 
-> [!IMPORTANT]
-> **VETH Pair Limitation:** When using VETH pairs with containers, at least
-> one side of the pair must remain in the host namespace. It is currently
-> not possible to create VETH pairs where both ends are assigned to different
-> containers. One end must always be accessible from the host.
+> [!TIP]
+> Both ends of a VETH pair may be assigned to containers, connecting two
+> containers directly without involving the host namespace.
 
 [^3]: Something which the container bridge network type does behind the
     scenes with one end of an automatically created VETH pair.