[Anomaly Detector] CodeGen

[jsquire]

Summary

The focus of these changes is to regenerate code based on the v1.1-preview.1 version of the swagger.

[azure-sdk]

API changes have been detected in Azure.AI.AnomalyDetector. You can review API changes here

[mengaims]

@jsquire I've seen some checks still not successful for this PR and no reviewer approved. Is there any other things need me to do? Or you will help cover following things before merge?

[jsquire]

Hi @mengaims. There are still issues that need to be addressed. To echo what I reported on the email thread:

Please be aware that the new swagger version did cause a couple of issues that you’ll want to review:

• It introduced breaking changes due to new parameters being inserted in client constructors in the middle of the list.
• The “ApiVersion” type introduced is redundant to the “ServiceVersion” type in the client options and contains the same members
• The use of “ApiVersion” changes the pattern of specifying the service versions with the client options that is defined in the .NET guidelines. (ref)

I fixed the build issues with the tests that the breaking changes introduced, but did not re-record the tests using the new API which will be needed prior to merging.

I don't have much context around this package, but since it's under an Azure.[[ AREA ]] namespace, my assumption is that it is considered track two and should follow the API guidelines.

[mengaims]

@jsquire Thanks for your comments!
I've commited some changes in this PR to resolve the build issues, including: update snippets and record tests. I also ran the Export-API.ps1 in local successfully but it seems the generated file could not be committed. Could you please help review and merge my PR? And if it's possible, could you add me to the contributor of your branch so that I could push commits directly to check the build status timely.
And for your previous comments, here are my answers:
Regarding to the breaking change, yes this version we have some breaking changes so that we upgrade the api version.
And for the "ApiVersion", we introduced this parameter following the API swagger guidance, what will happen when different values are assigned to "ApiVersion" and "ServiceVersion"? Is it possible to fix this redundant in our next version?

[jsquire]

@mengaims: I merged your updates in. Unless you made additional changes to the API surface by regenerating the code, you shouldn't need to export the API again - I did that after generating and it's included here. We'll see if something gets cranky during CI. So long as CI passes, you're free to sign off on this PR and we'll get things merged into main.

With respect to resolving the breaking changes and resolving the issues with the ApiVersion redundancy - that's not my call to make, that would be a discussion that is needed with the Azure SDK Architecture Board. To my knowledge, they're good with the preview going out as-is, but @lmazuel has been driving those conversations and would have the latest.

what will happen when different values are assigned to "ApiVersion" and "ServiceVersion"?

I honestly have no idea.

[jsquire]

@mengaims: Looks like CI is happy. Please feel free to approve at your convenience and I'll get things merged in.

[lmazuel]

Approved for preview