Deprecate modules with vmware.vmware replacements

[mikemorency]

Summary

Following up on the conversation from #502, I believe it is best to deprecate modules in this repository that have equivalent functionality in the vmware.vmware collection. Here are the reasons I feel like this is the right move for this repo:

1. This repository requires the use of the "turbo server" from cloud.common. This is basically a caching mechanism that speeds up module execution. However, the speed comes at a significant cost of complexity and obfuscation. Whenever users have issues with the turbo server, it is very time consuming and difficult to debug. It would be better to steer users (especially less experienced ones) towards a more user friendly experience.
2. Having multiple modules that do the same thing creates extra work for maintainers, and confusion for people unfamiliar with the vmware collections.
3. This repo's module code is automatically generated based on the vCenter API spec. This causes a lot of extra work for maintainers. Its not easy to add functionality or fix bugs, and we are dependent on another repo upstream which does not get a lot of attention. Also because the API spec drives this repos content, we cannot perform major releases as we normally would to say, deprecate Ansible versions.

I know this collection works well for some people or they have reasons to prefer this over other collections. My plan would be to deprecate modules but with no specific deprecation date in mind. The next major release could be when the next major vSphere API comes out or when Ansible core gets too far ahead of our minimum supported version. I can say, it will not be soon.

Code of Conduct

• I agree to follow the Ansible Code of Conduct

Affected Modules And Their Replacements

• vcenter_vmtemplate_libraryitems_info -> vmware.vmware.content_library_item_info
• vcenter_vm_hardware_memory_info -> vmware.vmware.vm_resource_info
• vcenter_vm_hardware_cpu_info -> vmware.vmware.vm_resource_info
• vcenter_vm_guest_networking_interfaces_info -> vmware.vmware.vm_portgroup_info
• vcenter_host -> vmware.vmware.esxi_host
• vcenter_cluster_info -> vmware.vmware.cluster_info
• content_subscribedlibrary -> vmware.vmware.subscribed_content_library
• content_locallibrary -> vmware.vmware.local_content_library
• appliance_networking_firewall_inbound -> vmware.vmware.vcsa_settings
• appliance_networking_firewall_inbound_info -> vmware.vmware.appliance_info
• appliance_access_consolecli -> vmware.vmware.vcsa_settings
• appliance_access_consolecli_info -> vmware.vmware.appliance_info
• appliance_access_ssh -> vmware.vmware.vcsa_settings
• appliance_access_ssh_info -> vmware.vmware.appliance_info
• appliance_access_shell -> vmware.vmware.vcsa_settings
• appliance_access_shell_info -> vmware.vmware.appliance_info
• appliance_access_dcui -> vmware.vmware.vcsa_settings
• appliance_access_dcui_info -> vmware.vmware.appliance_info
• appliance_access_shell -> vmware.vmware.vcsa_settings
• appliance_access_shell_info -> vmware.vmware.appliance_info
• appliance_networking_proxy -> vmware.vmware.vcsa_settings
• appliance_networking_proxy_info -> vmware.vmware.appliance_info
• appliance_networking_noproxy -> vmware.vmware.vcsa_settings
• appliance_networking_noproxy_info -> vmware.vmware.appliance_info
• appliance_ntp -> vmware.vmware.vcsa_settings
• appliance_ntp_info -> vmware.vmware.appliance_info
• appliance_timesync -> vmware.vmware.vcsa_settings
• appliance_timesync_info -> vmware.vmware.appliance_info
• appliance_networking_dns_domains -> vmware.vmware.vcsa_settings
• appliance_networking_dns_domains_info -> vmware.vmware.appliance_info
• appliance_networking_dns_servers -> vmware.vmware.vcsa_settings
• appliance_networking_dns_servers_info -> vmware.vmware.appliance_info
• appliance_networking_dns_hostname -> vmware.vmware.vcsa_settings
• appliance_networking_dns_hostname_info -> vmware.vmware.appliance_info
• appliance_system_time_timezone -> vmware.vmware.vcsa_settings
• appliance_system_time_timezone_info -> vmware.vmware.appliance_info
• appliance_system_globalfips -> vmware.vmware.vcsa_settings
• appliance_system_globalfips_info -> vmware.vmware.appliance_info

[mariolenz]

I agree, especially about having multiple modules that do at least more or less the same thing. This creates extra (unnecessary) work for maintainers and might confuse users. For example, at the moment we have:

• community.vmware.vmware_cluster_info
• vmware.vmware.vcenter_cluster_info
• vmware.vmware.cluster_info

Let's join our forces by deprecating the modules that are (basically) duplicates 💪

My plan would be to deprecate modules but with no specific deprecation date in mind.

I'm not 100% sure, but I think you have to define when a module will be removed. However, I also think you can have "TBA" for removal_version / removed_in ;-)