ssh-2.0.9 breaks backwards compatibility with older Azure CLI versions < 2.71.0

[Joshua-Barclay]

Describe the bug

The recent upgrade of the extension ssh to version 2.0.9 #9778 has introduced a dependency on a later version of Azure CLI without updating azext_metadata.json. Users with pinned versions of azure-cli < 2.71, installing a non-pinned version of ssh will install the incompatible version 2.0.9.

Reproduction steps

# Install a pinned version of Azure CLI
choco install azure-cli --version=2.56.0 -y
# Install the latest compatible version of the ssh extension
az extension add --name ssh --system
# Run az ssh vm
az ssh vm --ip xx.xx.xx.xx

Related command

az extension add --name ssh
az ssh vm --ip xx.xx.xx.xx

Errors

The command failed with an unexpected error. Here is the traceback:
No module named 'azure.cli.command_modules.vm.operations'

 File "C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\azure-cli-extensions\ssh\azext_ssh\custom.py", line 63, in ssh_vm
    target_os_utils.handle_target_os_type(cmd, ssh_session)
  File "C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\azure-cli-extensions\ssh\azext_ssh\target_os_utils.py", line 23, in handle_target_os_type
    os_type = _get_azure_vm_os(cmd, op_info.resource_group_name, op_info.vm_name)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\azure-cli-extensions\ssh\azext_ssh\target_os_utils.py", line 54, in _get_azure_vm_os
    from azure.cli.command_modules.vm.operations.vm import VMShow
ModuleNotFoundError: No module named 'azure.cli.command_modules.vm.operations'

Issue script & Debug output

az --version
azure-cli                         2.56.0
az extension list-versions --name ssh
# truncated for clarity
  {
    "compatible": true,
    "experimental": false,
    "installed": true,
    "name": "ssh",
    "preview": false,
    "version": "2.0.9 (max compatible version)"
  }

### Expected behavior

`ssh` version `2.0.9` should have compatibility restricted to `azure-cli` version >= `2.71.0`

Executing `az extension add --name ssh` with `azure-cli` < `2.71.0` should install version `2.0.8`, which is the last compatible version.

### Environment Summary

azure-cli                         2.56.0

core                              2.56.0
telemetry                          1.1.0

Extensions:
azure-devops                       1.0.4
resource-graph                     2.1.1
ssh                                2.0.9

Dependencies:
msal                            1.24.0b2
azure-mgmt-resource             23.1.0b2

Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\[username]\.azure\cliextensions'
Extensions system directory 'C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\azure-cli-extensions'

Python (Windows) 3.11.5 (tags/v3.11.5:cce6ba9, Aug 24 2023, 14:38:34) [MSC v.1936 64 bit (AMD64)]

### Additional context

`azure.cli.command_modules.vm.operations.vm import VMShow` appears to have been introduced in `azure-cli` version `2.71.0`

[yonzhan]

ssh

[mvanhorn]

Opened #10107 to address this: it raises the ssh extension's azext.minCliCoreVersion to 2.71.0 and ships it as 2.0.10 so the compatibility resolver stops offering the AAZ-based build to azure-cli cores older than 2.71.0 and installs 2.0.8 there instead.

[Joshua-Barclay]

@mvanhorn thanks for having a look at this issue. I'm not familiar with the Azure compatibility resolver so I might be wrong, but won't version 2.0.9 remain the latest compatible version for older Azure CLI versions even after this release? My understanding of your fix is that it would prevent 2.0.10 and onwards being picked up by older Azure CLI versions.

With my (albeit limited) understanding of the compatibility resolver, I believe version 2.0.9 would need to be republished with the correct azext.minCliCoreVersion, which is probably not an allowed process (republishing versions).

Alternatively, the old release 2.0.8 could be republished as 2.0.10, and then current 2.0.9 could be republished as 2.0.11 but with the correct azext.minCliCoreVersion, however this would briefly introduce an unexpected regression for anyone dependent on features in the current 2.0.9.