Add token mapping strategies with inferred fallback

[VenelinMartinov]

This PR adds two new token mapping strategies for providers which add a fallback to the InferredModules strategy:

• KnownModulesWithInferredFallback is equivalent to KnownModules but with a fallback
• MappedModulesWithInferredFallback is equivalent to MappedModules but with a fallback

This should make token mapping for all providers easier since we can migrate all KnownModules providers to KnownModulesWithInferredFallback and all MappedModules to MappedModulesWithInferredFallback

The two strategies are written to make automated migrations using gopatch easy and are separated in a different module.

Related to pulumi/ci-mgmt#1347

[codecov]

Codecov Report

Attention: Patch coverage is 73.80952% with 11 lines in your changes missing coverage. Please review.

Project coverage is 67.76%. Comparing base (a801f99) to head (5f80504).
Report is 9 commits behind head on master.

Files with missing lines	Patch %	Lines
...tfbridge/tokens/fallbackstrat/fallback_strategy.go	73.80%	8 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2882      +/-   ##
==========================================
+ Coverage   67.74%   67.76%   +0.02%     
==========================================
  Files         328      329       +1     
  Lines       42116    42176      +60     
==========================================
+ Hits        28531    28581      +50     
- Misses      11994    12003       +9     
- Partials     1591     1592       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iwahbe]

Is there a reason we can't expose a much simpler tokens.CombineStrategies(strategies ...Strategy) Strategy api?

The tokens.CombineStrategies would just try each strategy in turn until one works.

KnownModulesWithInferredFallback and MappedModulesWithInferredFallback seems like specialization that adds complexity.

[VenelinMartinov]

We could but that'd expose a wider public area which we are committing to maintaining. The WithInferredFallback variants are our only current use case for CombineStrategies and expose a much narrower surface area. This will in turn allow us to

• refactor as we see fit
• Expose CombineStrategies in the future if needed

In addition, because some of the config is shared, we can use the first strategy inputs to configure the InferredModules strat and automate the whole migration for all providers

[guineveresaenger]

Can you summarize what this change does, and when it would apply?

Holding for @iwahbe to respond to your comment.

Thank you for all these improvements!

[iwahbe]

We could but that'd expose a wider public area which we are committing to maintaining. The WithInferredFallback variants are our only current use case for CombineStrategies and expose a much narrower surface area. This will in turn allow us to

• refactor as we see fit
• Expose CombineStrategies in the future if needed

We are already committed to exposing the strategy for KnownModules, MappedModules and InferredModules. The additional overhead to exposing an or combinator is extremely minimal. IMO it is less overhead then exposing *WithInferredFallback functions.

In addition, because some of the config is shared, we can use the first strategy inputs to configure the InferredModules strat and automate the whole migration for all providers

That design makes me pretty uncomfortable. Field X is required unless it is being passed to a function that will fill it in leads to a very confusing space.

[iwahbe]

Looking at this API, I'm wondering if we want to distinguish error types. The safest thing to do would be to introduce a StrategyDoesNotApply error, and then only forward calls when the strategy returns an error that wraps that.

This would allow stratagies to signal critical failures vs simply not applying.

[iwahbe]

2 nits in the documentation, then LGTM

[pulumi-bot]

This PR has been shipped in release v3.103.0.