Remove ad-hoc api versions

[jiasli]

Several command modules use ad-hoc api versions for azure-mgmt-network SDK (https://github.com/Azure/azure-cli/pull/17816):

https://github.com/Azure/azure-cli/blob/3e26929f7669c504a5720e7f63c4be729534d52e/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L406-L416

These API versions are preserved when trimming the azure-mgmt-network SDK:

https://github.com/Azure/azure-cli/blob/fcbce9717c7825913a6a62fb6d26ba5a8d6ea326/build_scripts/windows/scripts/remove_unused_api_versions.py#L18-L20

This leads to bigger Azure CLI package.

The solution is to migrate to the latest API version:

https://github.com/Azure/azure-cli/blob/3e26929f7669c504a5720e7f63c4be729534d52e/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L155

[jiasli]

vm_default_target_network: @zhoxing-ms nw_connection_monitor: @necusjz container_network: @joseph-porter appservice_network, appservice_ensure_subnet: @panchagnula

[zhoxing-ms]

'vm_default_target_network': '2018-01-01'

The reference of Compute module to vm_default_target_network is mainly divided into two cases:

1. ARM template deployment
   • build_public_ip_resource
   • build_load_balancer_resource

In this case, Python SDK will not be used, so it will not affect the reduction of SDK package size. In order to ensure the feature stability and keep consistent with the api-version settings of other resources, we will continue to hard code an independent api-version for this case.

2. Get network client
   • _validate_vm_vmss_create_vnet
   • _get_default_address_pool
   • _validate_vmss_create_load_balancer_or_app_gateway
   • get_network_lb
   • get_vm_details

This case will lead to unnecessary Python SDK version dependency. The reason for the previous design was to avoid excessive re-recording of the yaml files of Compute module when bumping the api-version for network RP: https://github.com/Azure/azure-cli/blob/34fe3899ca8ad4e569ae012f0f5e2594291e8167/src/azure-cli/azure/cli/command_modules/vm/_vm_utils.py#L25-L29 But fortunately, we now have the bumping version pipeline to help solve this problem, so they can be modified to use the api-version of Network module. @necusjz Please be aware~

[panchagnula]

appservice_ensure_subnet

@madsd before I make the changes to use the latest version / default-version, wanted to check if there is a reason we use an ADhoc version for ASE & access-restrictions on App Service? Can these be safely removed?

[madsd]

@panchagnula as I recall, this was to force to a newer API when this was developed as the "default" did not support delegations. This should not be a problem now.

[panchagnula]

@panchagnula as I recall, this was to force to a newer API when this was developed as the "default" did not support delegations. This should not be a problem now.

Thanks for reviewing & sign-off on PR as well @madsd

[necusjz]

Let's remove them in the coming breaking change window.

[jiasli]

Another ad-hoc API version used by appservice command module:

https://github.com/Azure/azure-cli/blob/daa3b68229589948f7544c4aa12404618df81584/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L3009

[jiasli]

ACR also has a bunch of ad-hoc API versions: https://github.com/Azure/azure-cli/blob/53c9ce261bd9db21ee02bd4247577deff512d37e/src/azure-cli/azure/cli/command_modules/acr/_client_factory.py#L8-L12

[jiasli]

ACS also has ad-hoc API version:

https://github.com/Azure/azure-cli/blob/9a6baa9462fa463a05fe62ca4827e5235623c163/src/azure-cli/azure/cli/command_modules/acs/tests/latest/test_custom.py#L50-L52