Bug fix for CertificateInformation and add additional properties to ApiContract

[solankisamir]

Description

Azure/azure-rest-api-specs#3614
Azure/azure-rest-api-specs#3609
Azure/azure-rest-api-specs#3430

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• Please add REST spec PR link to the SDK PR
• I have read the contribution guidelines.
• The pull request does not introduce breaking changes.

General Guidelines

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

SDK Generation Guidelines

• If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
• The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code.
• The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK.

[solankisamir]

@shahabhijeet looks to be some issue with infra

[dsgouda]

Looks great apart from the comment

[dsgouda]

Please set this tag as the default tag in the REST spec. Is there a reason why you are picking a particular tag here?

[solankisamir]

Because we want the documentation to be generated off the -preview version, but the SDK to be targeted for specific stable version.

[dsgouda]

IIRC documentation is generated from the published nuget package, so SDK and documentation should ideally be the same version
@shahabhijeet could you please take a look

[shahabhijeet]

@solankisamir if your purpose is to generate against selective tag, then that selective tag should be the default tag in your Readme.md.
Basically you have tag1, tag2, tag3 for your various versions of spec files.
If you have decided to generate SDK against tag2, let tag2 be the default tag that all future SDKs will be generated, until you change it to something else.
You need to tie your intention to generate SDK in the rest spec repository Readme.md than generate.ps1 file in SDK repo.
Also how are JAVA, python SDKs suppose to get generate, who is keeping track as to which tag are they using?
This will cause a lot of confusion when we detect a security issue and have to regenerate and publish SDKs on a short notice.

[solankisamir]

@dsgouda updated the SDK generation to be agnostic of version.

[solankisamir]

@shahabhijeet @dsgouda a gentle ping on this!

[dsgouda]

LGTM

[dsgouda]

Apologize for the delay