Refactor: Move *Info objects out of /pkg/tfbridge to their own package: /pkg/tfbridge/info

[iwahbe]

This PR is a refactor to separate out the user's declaration of a provider (via tfbridge.*Info structs and the runtime behavior of the provider (via various tfbridge.* methods)

This PR moves /pkg/tfbridge.*Info and supporting types to /pkg/tfbridge/info.*. This allows finer grain dependency management, and crucially it allows a package to depend on user information /pkg/tfbridge/info but be importable by the runtime /pkg/tfbridge. To the greatest degree possible, this is a pure refactor. There are 3 unavoidable breaking changes:

1. tfbridge.MetadataInfo.ExtractRuntimeMetadata has been moved from a method on tfbridge.MetadataInfo (now info.Metdata) to a stand alone function: tfbridge.ExtractRuntimeMetadata. This function is public only to share with /pkg/tfgen and I do not expect users will call it. A GH search shows that only the bridge calls this function. I don't expect other repo to be impacted.
2. tfbridge.ProviderInfo.(Must)?TraverseProperties has been moved from a method to a standalone function: tfbridge.(Must)?TraverseProperties. A GH code search shows that this is only used in pulumi-gcp. pulumi-gcp is the only repo I expect to be impacted.
3. tfbridge.ElementStrategy[T Resource | DataSource] func(tfToken string, elem *T) error could not be re-exported since go does not allow type aliases for generic types. This type is largely internal to the bridge and a GH code search does not show any external usage. I don't expect any users to be effected here.

All other moved types and methods have been back-ported into tfbridge to avoid breaking existing providers. Consumers of the bridge shouldn't observe any changes, they are welcome to continue to use tfbridge.ProviderInfo and it will continue to work exactly as it previously did.

This PR consists entirely of name changes. There are no logic changes, alterations, improvements, etc. The bodies of all functions and types are unchanged.

[codecov]

Codecov Report

Attention: Patch coverage is 84.66948% with 109 lines in your changes are missing coverage. Please review.

Project coverage is 60.06%. Comparing base (45d8f28) to head (de2933b).

Files	Patch %	Lines
pkg/tfbridge/info/assets.go	62.88%	29 Missing and 7 partials ⚠️
pkg/tfbridge/info/info.go	93.63%	15 Missing and 5 partials ⚠️
pkg/tfbridge/info/autonaming.go	72.58%	12 Missing and 5 partials ⚠️
pkg/tfbridge/tokens/tokens.go	77.27%	10 Missing and 5 partials ⚠️
pkg/tfbridge/info.go	22.22%	7 Missing ⚠️
pkg/tfbridge/info/rename.go	91.42%	4 Missing and 2 partials ⚠️
pkg/tfbridge/provider.go	66.66%	2 Missing and 1 partial ⚠️
pkg/tfbridge/tokens/inferred_modules.go	76.92%	2 Missing and 1 partial ⚠️
pkg/tfbridge/walk.go	66.66%	1 Missing ⚠️
pkg/tfgen/generate.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1879   +/-   ##
=======================================
  Coverage   60.06%   60.06%           
=======================================
  Files         323      327    +4     
  Lines       43894    43919   +25     
=======================================
+ Hits        26363    26381   +18     
- Misses      16040    16047    +7     
  Partials     1491     1491           

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

[VenelinMartinov]

it allows a package to depend on user information /pkg/tfbridge/info but be importable by the runtime /pkg/tfbridge

Could you give an example use case of this? Would the bridge depend on a specific provider?

[iwahbe]

it allows a package to depend on user information /pkg/tfbridge/info but be importable by the runtime /pkg/tfbridge

Could you give an example use case of this? Would the bridge depend on a specific provider?

The bridge would not depend on any specific provider. The motivating use case is introducing a new package: /pkg/convert/state which would import /pkg/tfbridge/info, /pkg/tfshim and be imported by /pkg/tfbridge and /pf/tfbridge.

[VenelinMartinov]

lgtm

[t0yv0]

Looking at this before my conclusion was that we inevitably will need to break out the tfbridge package or else all new code has to live in the same package (pretty much), and that Go does not make it easy, but I hesitated to do so as not to cause irritation and extra work for our consumers the link-depend on this code such as Cosmic. If there are changes that a provider maintainer needs to take here to accommodate this upgrade, I'd expect the bridge release to have instructions on how to do it. Perhaps that'd be sufficient. Thanks!