Read "official" default API versions from spec readmes

[thomas11]

TODO

• 4 modules have "composite" or empty versions
• because we're reading the readme.md files from main or close to it, we're picking versions that are too new
• not taking into account service groups
  • most modules have a single readme.md here: quota/resource-manager/readme.md
  • but service groups have one per service:
    • containerservice/resource-manager/Microsoft.ContainerService/aks/readme.md
    • containerservice/resource-manager/Microsoft.ContainerService/fleet/readme.md
  • they can have different API versions
  • some modules like workloads even have the op-level readme and service group readmes; not sure what that means
• make this new way of getting default versions easily swappable with the previous one
• allow manual overrides

[github-actions[bot]]

Does the PR have any schema changes?

Looking good! No breaking changes found. No new resources/functions.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 12.12121% with 116 lines in your changes missing coverage. Please review.

Project coverage is 57.06%. Comparing base (927be8f) to head (b990681).

Files with missing lines	Patch %	Lines
provider/pkg/resources/resources.go	1.72%	57 Missing :warning:
provider/pkg/openapi/discover.go	2.22%	44 Missing :warning:
provider/cmd/pulumi-gen-azure-native/main.go	0.00%	12 Missing :warning:
provider/pkg/openapi/defaultApiVersions.go	82.35%	2 Missing and 1 partial :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3996      +/-   ##
==========================================
- Coverage   57.52%   57.06%   -0.46%     
==========================================
  Files          82       83       +1     
  Lines       13096    13225     +129     
==========================================
+ Hits         7533     7547      +14     
- Misses       4987     5101     +114     
- Partials      576      577       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[EronWright]

I was thinking that we would avoid duplication of their core parsing logic by having our tools consume the "code model" that is produced by autorest - the intermediate data format that autorest generates before doing language-specific code generation (across all languages supported by the Azure SDK). This is possible by running autorest with a certain flag to retain the code model, or by installing an autorest language plugin (that would target Pulumi schema).

Have you considered an approach like that?

Update: here's an example of that approach in action, in this case to generate the bicep schema files. What's missing here is fuller coverage of the resource functions, and perhaps more information about parentage and how to construct the full REST API path for a given resource.

https://github.com/Azure/bicep-types-az