Bug 2016337

> Description of problem:
lldpad service fails to start due to loading a huge configuration file full of interfaces that have been removed.

> Version-Release number of selected component (if applicable):
RHEL8(1.0.1-16.git036e314), RHEL7(lldpad-1.0.1-5.git036e314) and upstream all affected

> How reproducible:
Always

> Steps to Reproduce:
1. Fresh install a RHEL7.9/RHEL8.4

2. Install the latest lldpad package

# yum install lldpad

3. Enable the lldpad service

# systemctl enable lldpad

4. Reboot the system

5. Ensure the lldpad service is running and check the recorded interfaces:

# systemctl status lldpad
# cat /var/lib/lldpad/lldpad.conf | grep ':' | grep '^[[:space:]]\{2\}[a-z]' | sort -u

6. Create virtual ethernet tunnels and make it up:

# for i in {1..50}; do ip link add vetha$i type veth peer name vethb$i; ip link set vetha$i up; ip link set vethb$i up; done

7. Delete all these interfaces:

# for i in {1..50}; do ip link set vetha$i down; ip link del vetha$i; done

8. Check the recorded interfaces again:

# cat /var/lib/lldpad/lldpad.conf | grep ':' | grep '^[[:space:]]\{2\}[a-z]' | sort -u

9. Reboot the server

10. Check lldpad service status and the recorded interfaces:

# systemctl status lldpad
# cat /var/lib/lldpad/lldpad.conf | grep ':' | grep '^[[:space:]]\{2\}[a-z]' | sort -u

> Actual results:
The /var/lib/lldpad/lldpad.conf recorded all interfaces information though the veth ones have been deleted.

> Expected results:
The lldpad should only check for the valid interfaces dynamically.

> Additional info:
With a huge config file, e.g. with more than 136k interfaces, the lldpad process will consume lots of CPU during its startup and fails to start at last.

NO upstream fix at this moment.