Remove VMs and Hosts on HMC provider removal

[Kummari-Yeshwanth]

Summary

Delete HMC inventory when a provider is removed instead of leaving the inventory in an archived state.

Changes

• Added a provider setting to control inventory deletion on provider removal.
• Added HMC-specific handling during provider removal.
• Delete associated VMs and Hosts before the provider is destroyed.

[agrare]

This feels like something we could do in core (not necessarily exactly this way) if people don't want to keep this type of inventory around, @Fryguy ?

[Fryguy]

Agreed. An option when deleting a provider would be welcome across the board.

Note that even if the user decides to remove all of the inventory, I don't think this PR is the right way to do it. We've seen instances where deleting all of the VMS and hosts and everything can take a very long time because there's a lot of associated records. For example, if you had 10,000 VMS, this is deleting them one by one which can get very expensive.

I recall us putting the provider in maintenance mode first and then doing some other things. Maybe that's what orchestrate destroy does... I can't remember offhand.

[Fryguy]

Please also rebase this PR and don't use merge commits as described by the bot

[agrare]

I recall us putting the provider in maintenance mode first and then doing some other things. Maybe that's what orchestrate destroy does... I can't remember offhand.

Yes that is what orchestrate_destroy does.

ETA: Well technically orchestrate_destroy pauses the provider and waits for all workers to exit, the original intention wasn't to pre-destroy dependent associations that could take a long time but that's not a bad secondary benefit actually. Normally we've relied on purging to do this.

[miq-bot]

Checked commit Kummari-Yeshwanth@b3f905d with ruby 3.3.10, rubocop 1.86.0, haml-lint 0.73.0, and yamllint 1.37.1
1 file checked, 0 offenses detected
Everything looks fine. ⭐

[Fryguy]

Ok, right, so the way orchestrate_destroy is being used in this PR is not correct. Here it deletes all the vms and hosts then calls super, so if there are active ems workers running they would put the vms and hosts right back. Also, orchestrate_destroy does this all on the queue with a task_id, which this code bypasses.

I think the right way to do this is to override EMS#disconnect_inv (or implement this optional delete logic there for all providers), but I'm having trouble walking whether that would work or not.