[FEATURE REQ] Support new SDK generation pipeline

[XiaofeiCao]

New SDK PR generation is using SDK automation script.

Doc: https://eng.ms/docs/products/azure-developer-experience/develop/sdk-generation-pipelines
Pipeline run: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=4618998&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=c10d5f44-55ce-55d7-7975-407ed75d9a96

Existing gaps:

1. Changelog comparison. For SDK, beta->last released version, GA -> last released GA.
2. Log enhancement.
3. Version

We probably need unification of SDK generation and SDK automation.

[maririos]

Just by reading this, and not having much context, it is not clear what are the specific Java requirements that no other language has that makes it hard for Java to move to the new SDK generation pipeline.
For example:

• What is the problem with the changelog? is this unique to Java? or does it happen to all languages?
• What are the log enhancements?
• What happens with the version? version of what?

[weidongxu-microsoft]

I think most of this is for script part. And should be solved by Xiaofei alone.

What we need from pipeline input is the "api-version" of the service to be released. (I think we had agreement with Ray to have this option in pipeline -- and Ray replied in email)
Service need to use this to confirm on their intended "api-version" to release (their TypeSpec source may already in later api-version), and automation would use this info to calculate the next SDK version (e.g. if api-version is stable then it be 1.1.0, otherwise 1.1.0-beta.1). Also, changelog would be affected.

[XiaofeiCao]

@maririos Current Java use different script entry for SDK automation and SDK generation, as they serve two different purposes. Hence there are some differences with the generated SDKs.
e.g. Changelog/(breaking change detection),
SDK automation generates breaking changes by comparing APIs with latest GA version to ensure all breaking changes be explicitly addressed by service.
SDK generation generates beta SDKs' breaking changes/features by comparing with last released version, for the SDK user to see what's been added/changed.

And yes, as Weidong mentioned, these gaps should be Java alone. The change would be minimal, as their underlying implementations share a lot in common, and the difference is mainly on the entry.