…gin API

Example:
Given a bidning name 'dummy' and a NetworkAttachmentDefinition named
'dummy-net-binding', Kubevirt config should be set as follows:
  ---
  apiVersion: kubevirt.io/v1
  kind: KubeVirt
  metadata:
    name: kubevirt
    namespace: kubevirt
  spec:
    configuration:
      developerConfiguration:
        featureGates:
        - NetworkBindingPlugins
      network:
        binding:
          dummy:
            networkAttachmentDefinition: dummy-net-binding
  ...

In follow-up commits, the registered net-attach-def will be added to
the VM virt-launcher pod's Multus network CNI annotation.

Signed-off-by: Or Mergi <ormergi@redhat.com>

Add the specified network binding plugin NetworkAttachmentDefinition
to the VM virt-launcher pod's Multus annotation.

If no NetworkAttachmentDefinition is registered (specified in Kubevirt
config) its a no-op.

This change enable invoking additional CNI chains on virt-launcher pod
before it starts along others using network the binding plugin API.

Kubevirt adds the registered NetAttachDef to the VM pod Multus network
selection annotation, along with CNI args that includes the subject
interface logical network name.

The binding plugin CNI (specified in the binding plugin NetAttachDef)
should read the logical-network-name CNI arg to realize which logical
network it should modify.

virt-controller vmi unit tests will be adapted to new changes in
follow-up commit.

Signed-off-by: Or Mergi <ormergi@redhat.com>

Generating multus annotations now depends on cluster config.
Passing the tests cluster config to NewPodForVirtualMachine
makes it cumbersome and requires changing all the tests that use it.

Thus, introduce new factory for creating pod with multus annotations.

The tests fake cluster config is moved to global scope to enable access
for tests the needs it; tests that generates multus annotations.

Signed-off-by: Or Mergi <ormergi@redhat.com>