Azure DevOps pipeline for releasing the library to nuget.org and github releases

[danielmbaluka]

Fixes #136

Changes in this PR

• Added a new Azure DevOps pipeline for automatically building and releasing the package to nuget.org and github releases. The pipeline is configure to be triggered on github tags
• Disabled delay signing as recommended in https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming.
• Generated a new strong name signing key for the library that will be used for both debug and release builds

[danielmbaluka]

The pipeline is currently failing because of a key permission issue
Failed OperationId: 458d5fc7-d8a6-498d-b50f-653a5077485b, Status: FailDoNotRetry, FilePath:D:\a\1\s\bin\Release\net472\Microsoft.OpenApi.OData.Reader.dll, Error: {"code":"NeoSigningServiceFailedError","details":{"error":"An exception occurred in the NEO StaticSigner service.","exception":"This clientId *** is unauthorized to access MSSharedLibSnKey"},"innerError":null}
https://microsoftgraph.visualstudio.com/Graph%20Developer%20Experiences/_build/results?buildId=64223&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=094908eb-9b91-5864-e5bc-10e3f5697105

[baywet]

The main workflow seems to be failing now because of a relative path issue.
adding workingDirectory: $(Build.SourcesDirectory)\src\Microsoft.OpenApi.OData.Reader\
under

OpenAPI.NET.OData/.github/ISSUE_TEMPLATE/workflows/azure-pipelines_rolling.yml

Line 58 in dbcf686

projects: '$(Build.SourcesDirectory)\src\Microsoft.OpenApi.OData.Reader\Microsoft.OpenAPI.OData.Reader.csproj'

should fix that

more information

[baywet]

(see my previous comment)

[danielmbaluka]

@xuzhg @darrelmiller I would appreciate your reviews on this PR. The significant change in this PR is using the newly generated SNK key for strong name signing. This replaces the shared "MSSharedLibSnKey" which required us to use do delay signing as the private key is only accessible by the Azure pipeline.

[baywet]

@danielmbaluka ready to merge whenever you want. One gotcha @zengin and I noticed a while ago, when you update the triggers on the pipeline definition, it may not necessarily reflect the changes in ADO. You might have to manually reflect the changes on the build definition's settings.