SecurityType parameter set to Standard by default

[AjKundnani]

Describe the bug

ASK: Send Standard value of parameter --security-type to backend API ONLY IF explicitly set by end user. Default should be TrustedLaunch or null as part of Trusted launch as default implementation

Change implemented for #30728 has enabled Standard security type as default for all scenarios which does not support TrustedLaunch including Gen1 OS images and Azure Compute Gallery images.
Request to scope the change #30728 only to user defined --security-type=Standard.

This should resolve related issues #31232, #31195, #31191 to major extent.

Related command

az vm create
az vm update
az vmss create
az vmss update

Errors

Error from backend API in absence of feature flat Microsoft.Compute\UseStandardSecurityType

{
"innererror": {
"internalErrorCode": "ParameterValueInvalid"
},
"code": "InvalidParameter",
"message": "The value of parameter securityProfile.securityType is invalid.",
"target": "securityProfile.securityType"
}

Issue script & Debug output

Refer to related issues #31232, #31195, #31191

Expected behavior

• CLI will send --security-type=Standard to backend ONLY if explicitly set by end users.
• Else CLI will default --security-type = TrustedLaunch OR null as per existing logic.

Environment Summary

Refer to related issues #31232, #31195, #31191

Additional context

At time of implementing Trusted launch as default, Standard translated to null in backend.
However, as we're ramping up and planning for Trusted launch as default in backend API, the API understands Standard as accepted enum value for SecurityType IF AFEC Microsoft.Compute\UseStandardSecurityType is registered on subscriptions

[yonzhan]

Thank you for opening this issue, we will look into it.