Address the cases where a NIC has a different name in kdump kernel
    
    Resolves: bz2076416
    Upstream: Fedora
    Conflict: None
    
    commit 568623e69a32266a3b00225b9de6a93435c44474
    Author: Coiby Xu <coxu@redhat.com>
    Date:   Thu Sep 23 14:25:01 2021 +0800
    
        Address the cases where a NIC has a different name in kdump kernel
    
        A NIC may get a different name in the kdump kernel from 1st kernel
        in cases like,
         - kernel assigned network interface names are not persistent e.g. [1]
         - there is an udev rule to rename the NIC in the 1st kernel but the
           kdump initrd may not have that rule e.g. [2]
    
        If NM tries to match a NIC with a connection profile based on NIC name
        i.e. connection.interface-name, it will fail the above bases. A simple
        solution is to ask NM to match a connection profile by MAC address.
        Note we don't need to do this for user-created NICs like vlan, bridge and
        bond.
    
        An remaining issue is passing the name of a NIC via the kdumpnic dracut
        command line parameter which requires passing ifname=<interface>:<MAC> to
        have fixed NIC name. But we can simply drop this requirement. kdumpnic
        is needed because kdump needs to get the IP by NIC name and use the IP
        to created a dumping folder named "{IP}-{DATE}". We can simply pass the
        IP to the kdump kernel directly via a new dracut command line parameter
        kdumpip instead. In addition to the benefit of simplifying the code,
        there are other three benefits brought by this approach,
          - make use of whatever network to transfer the vmcore. Because  as long
            as we have the network to we don't care which NIC is active.
          - if obtained IP in the kdump kernel is different from the one in the
            1st kernel. "{IP}-{DATE}" would better tell where the dumped vmcore
            comes from.
          - without passing ifname=<interface>:<MAC> to kdump initrd, the
            issue of there are two interfaces with the same MAC address for
            Azure Hyper-V NIC SR-IOV [3] is resolved automatically.
    
        [1] https://bugzilla.redhat.com/show_bug.cgi?id=1121778
        [2] https://bugzilla.redhat.com/show_bug.cgi?id=810107
        [3] https://bugzilla.redhat.com/show_bug.cgi?id=1962421
    
        Signed-off-by: Coiby Xu <coxu@redhat.com>
        Reviewed-by: Thomas Haller <thaller@redhat.com>
        Reviewed-by: Philipp Rudo <prudo@redhat.com>
    
    Signed-off-by: Coiby Xu <coxu@redhat.com>