Description of problem:
When a running VM changes (adds/removes/updates) an interface, the changes will occur on the VMI only after reboot, but kubemacpool performs the changes immediately, hence creating an inherent diff between the macMap and what is actually consumed.

For example, If a running VM removes an interface, the MAC will be removed from the macMap, while the VMI is still using it, effectively exposing the MAC for duplication.

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

How reproducible:
100%

Steps to Reproduce:
1. Create a running VM (=VM1) with 1 secondary interface, remember the MAC assigned.
2. Remove the secondary interface
3. Create another VM (=VM2), using the MAC assigned to VM-1.

Actual results:
Kubemacpool should reject VM2

Expected results:
Kubemacpool allows creation of VM2.

Additional info:
Since Kubemacpool assigned MACs consecutively, the issue should not manifest unless one of the 2 occurs:
1. Kubemacpool assigned all the free MACs in the range, and circles back to this MAC.
2. The user specifically chooses the MAC, overriding the consecutive MAC assignment.