Description of problem:

ZTP DU workflow provisions SriovOperatorConfig resource.
For SNOs, the SriovOperatorConfig resource includes configDaemonNodeSelector set to "master".
If at a later time SNO is expanded with one or more workers, SRIOV operator would not create sriov-device-plugin and  sriov-network-config-daemon pods on the worker node(s). Any attempt to change the configDaemonNodeSelector will result in create sriov-device-plugin and  sriov-network-config-daemon pods restart and possible network connectivity loss.

Suggest to provision configDaemonNodeSelector set to "worker", which should fit all the deployment types known so far (both SNO and 3NC nodes have the "worker" label, and will be selected)

For the users that already have configDaemonNodeSelector deployed with "master" selector, it should be documented that SNO expansion will incur sriov-device-plugin and  sriov-network-config-daemon pods restart on the master node

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Add worker node to SNO
2. Deploy SR-IOV configuration
3.

Actual results:

SR-IOV pods are not deployed on worker

Expected results:

SR-IOV pods are deployed on worker

Additional info:
https://github.com/openshift-kni/cnf-features-deploy/blob/dd1322d7f77d4e4fc56badfd04c9b4d8d7c6e05f/ztp/gitops-subscriptions/argocd/example/policygentemplates/group-du-sno-ranGen.yaml#L57

https://github.com/openshift-kni/cnf-features-deploy/blob/dd1322d7f77d4e4fc56badfd04c9b4d8d7c6e05f/ztp/source-crs/SriovOperatorConfig.yaml#L10

The fix might need to be backported