Fixes #36980 - Update the Lifecycle environment and content view for the host with new hostgroup

[lfu]

Hosts > All Hosts > select the Host > Select action > Change Group > Assign a HostGroup > Submit

Host should be updated with the Lifecycle environment and content view that are associated with the new hostgroup.

[jeremylenz]

Some concerns / questions:

1. Without host.hostgroup = hg, isn't this applying attributes from the new hostgroup without actually assigning that hostgroup to the host?

2. Without :validate => false, I'm concerned this .update may fail sometimes and just return false, resulting in a non-updated host.

3. Should all inherited attributes be applied when editing a hostgroup? When the host already has values for the inherited fields, are we handling all those properly and consistently? Is it correct to have the hostgroup inheritance override fields, even if they've been changed for a host? Would be good to get input from some well-versed Foreman folks. @ares @stejskalleos ?

4. This change is in the controller, which only comes into play when an API endpoint is hit. Shouldn't something change in the model, instead?

5. Should this code be in Katello and not Foreman, since it deals with changing content view and lifecycle environment? I could see doing it in host_managed_extensions as a before_update, maybe. (This would also satisfy the item above)

[lfu]

@jeremylenz Thanks for reviewing this.

1. Without host.hostgroup = hg, isn't this applying attributes from the new hostgroup without actually assigning that hostgroup to the host?

host.apply_inherited_attributes("hostgroup_id" => id) returns "hostgroup_id" => id + inherited_attributes in a hash. So the new hostgroup does not get lost.

2. Without :validate => false, I'm concerned this .update may fail sometimes and just return false, resulting in a non-updated host.

It does not make sense to me why :validate => false is required there when updating a host's hostgroup.
In this PR, I'm copying the behavior of Edit host to update a host group which is handled by this code.

3. Should all inherited attributes be applied when editing a hostgroup? When the host already has values for the inherited fields, are we handling all those properly and consistently? Is it correct to have the hostgroup inheritance override fields, even if they've been changed for a host? Would be good to get input from some well-versed Foreman folks. @ares @stejskalleos ?

all inherited attributes may look like "puppet_proxy_id"=>nil, "puppet_ca_proxy_id"=>nil, "compute_profile_id"=>nil, "realm_id"=>nil, "compute_resource_id"=>nil, "content_facet_attributes"=>{"kickstart_repository_id"=>nil, "content_view_id"=>2, "lifecycle_environment_id"=>2, "content_source_id"=>nil}.
I could slice out content_facet_attributes here for Change Group action if all is too much.

4. This change is in the controller, which only comes into play when an API endpoint is hit. Shouldn't something change in the model, instead?

Not sure what the issue is here.

5. Should this code be in Katello and not Foreman, since it deals with changing content view and lifecycle environment? I could see doing it in host_managed_extensions as a before_update, maybe. (This would also satisfy the item above)

I had the same debate as to where the change should locate. Hostgroup is a Foreman concept while LCE/CV delongs to Katello. But Change Group is handled by Foreman's /hosts/update_multiple_hostgroup.

[lfu]

Move the change to Katello.