Fixes #23174 - discovery with existing possible again

[lzap]

In PXE-less world, Foreman is no longer able to maintain PXE booting (menu) and users can easily run into situation when a host is discovered when there's already existing managed host. The recommended way is simply deleting the entry from Foreman's inventory prior rebooting the host. However, this requires manual reboot, probably accessing server's remote shell or console. Why not to leverage Foreman Remote Execution plugin to initiate the reboot? This requires the host to be present in the inventory to be able to perform the task. Some users might not prever deleting host explicitly.

In Foreman 1.14 (Discovery 9.x) and older, it is possible to discover an existing (managed) server, the problem arises during provisioning. With default naming convention (macAABBCCDDEEFF) provisioning will fail with "Name already taken" error, obviously the host name must be different from the existing system. This can be changed during provisioning in edit form, or by providing unique hostname pattern using random number for example in auto provisioning rule (recent version also allows to set own discoveryr naming pattern). Managed DHCP can also error out with "Unable to set DHCP entry: 409 Conflict" because MAC address DHCP reservation is already present. Obviously, this workflow can only work on unmanaged DHCP, DB or static IP address management. Having that said, changing the name and not using managed DHCP makes this possible and new host appears next to the old one after successful provisioning.

At this point, it is important to understand that provisioning tokens (Administer - Settings - Provisioning - token_duration) are required for successful OS installation. When token_duration is set to 0, incoming template request is matched via MAC address reported by Anaconda for Red Hat installer or via remote IP address for other OS installers instead of unique token. There are possible issues with multiple MAC addresses (the host is picked randomly) or multiple IP addresses (when IPAM is not integrated with DHCP). Symptoms can be different, but overall the expected host would not leave build mode in this case. It is worth metnioning that rediscovering already discovered host just refreshes node's facts and works as expected. It always worked this way.

Starting from Foreman 1.15 (Discovery 9.0) a patch prevents from discovering a node that already exist as a managed host in the inventory with error "Host already exists as managed". It turns out that this created a regression for PXE-less workflows. Therefore this patch creates an opt-in setting to keep that functionality, but by default existing PXE-less users will no longer be affected by the change. Discovery of existing hosts will work again.

To test the patch, deassociate DHCP and DNS from Subnet and Domain so there is no orchestration to avoid conflicts and set the Subnet to None or DB IPAM. Then discover a host with specific mac address. I've modified the helper script which can be used as:

discover-host -j rhel-r730 -i eth0,88,7,AA:BB:CC:DD:EE:FF

Provision with some name. Then discover again and provision under a different name. You should end up with two different hosts, note they will both have same provisioning MAC address - this is expected. Use tokens for provisioning if you want to do end to end testing (this is the default setting).

(Run unit tests locally, develop is red atm.)

[theforeman-bot]

Issues: #23174

[lzap]

Closing in fav of #423 - I pushed into wrong branch.