add Get-AzVmssVmRunCommand on SDK based cmdlet

[grizzlytheodore]

Description

This is mirroring what we already did to Get-AzVMRunCommand in the last release: #19272

Get-AzVmssVMRunCommand was originally autorest.powershell generated. But I am removing that from compute.autorest in this pr:
#19826

We are moving it to cmdlet built on SDK because we wanted to achieve two things:
Have all the fields show as a list format when we get back list of RunCommands
Have instanceView only show when -Expand InstanceView

So to achieve these customizations I moved it to cmdlet built on SDK here.

There is no breaking change here because currently from the documentation https://learn.microsoft.com/en-us/powershell/module/az.compute/get-azvmssvmruncommand?view=azps-9.0.0, 1st, 2nd, and 5th(last) parameter sets arent working

And the one parameter set we are adding in this PR is a combination of 3rd and 4th parameter sets by having -RunCommandName as optional.

Checklist

• Check this box to confirm: I have read the Submitting Changes section of CONTRIBUTING.md and reviewed the following information:

• SHOULD select appropriate branch. Cmdlets from Autorest.PowerShell should go to generation branch.
• SHOULD make the title of PR clear and informative, and in the present imperative tense.
• SHOULD update ChangeLog.md file(s) appropriately
  • For any service, the ChangeLog.md file can be found at src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md
  • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header in the past tense. Add changelog in description section if PR goes into generation branch.
  • Should not change ChangeLog.md if no new release is required, such as fixing test case only.
• SHOULD have approved design review for the changes in this repository (Microsoft internal only) with following situations
  • Create new module from scratch
  • Create new resource types which are not easy to conform to Azure PowerShell Design Guidelines
  • Create new resource type which name doesn't use module name as prefix
  • Have design question before implementation
• SHOULD regenerate markdown help files if there is cmdlet API change. Instruction
• SHOULD have proper test coverage for changes in pull request.
• SHOULD NOT introduce breaking changes in Az minor release except preview version.
• SHOULD NOT adjust version of module manually in pull request

[VeryEarly]

line 10 is breaking change

[grizzlytheodore]

wrote in the description above, but that parameter set was not working to begin with

[VeryEarly]

please try set VirtualMachineScaleSetVMRunCommandsClient.SubscriptionId
before this line:

azure-powershell/src/Compute/Compute/VirtualMachine/RunCommand/GetAzVmssVmRunCommand.cs

Line 75 in a81b266

VirtualMachineRunCommand vmssVmRc = VirtualMachineScaleSetVMRunCommandsClient.Get(this.ResourceGroupName, this.VMScaleSetName, this.InstanceId, this.RunCommandName, this.Expand);

[VeryEarly]

please list differences between IVirtualMachineRunCommand and PSVirtualMachineRunCommand to prove there are no breaking changes

[grizzlytheodore]

see IVirtualMachineRunCommand here:

azure-powershell/src/Compute/Compute.Autorest/generated/api/Models/Api20210701/VirtualMachineRunCommand.cs

Line 340 in 6bf2458

internal partial interface IVirtualMachineRunCommandInternal :

see PSVirtualMachineRunCommand here:

azure-powershell/src/Compute/Compute/Manual/PSVirtualMachineRunCommand.cs

Line 9 in a81b266

public class PSVirtualMachineRunCommand

all the properties match

[VeryEarly]

these two objects do not match, please check carefully, properties in IVirtualMachineRunCommand are flatten

[grizzlytheodore]

i see. you are right.

It is a little different and the return type will be changing. but the move from IVirtualMachineRunCommandInternal return type to PSVirtualMachineRunCommand has already been done for Get-AzVMRunCommand,

and essentially the current Get-AzVmssVMRunCommand is broken in numerous different places, so we are improving customer experience by making this transition from autorest generated to sdk based. You've already merged the PR that is removing this cmdlet from autorest, please let me know if this PR can be merged to complete the transfer despite the change in return type

[grizzlytheodore]

also @dingmeng-xue is aware of this migration, but here is the reasonings I sent him via email:

1. The feature owner wanted the returned output as list format.
   a. Even when we specify -RunCommandName to retrieve 1 RunCommand resource, it is returned in table format. The having ~10 properties that the user needed to see, the table format did not provide all the information needed for the users due to the PowerShell window size constraints.
2. Have instanceView properties only shown when -Expand is provided.
   a. The output was always showing “IntanceView” properties. So when “-Expand InstanceView” was not provided, those properties were always empty.

[grizzlytheodore]

and 2a is the result of having a flat hierchy

[VeryEarly]

got it, breaking changes on broken cmdlets won't be considered as blocker.

[grizzlytheodore]

please see my responses @VeryEarly