Add GenerateResourceConfig RPC

[stephybun]

Description

Adding the Generate Resource Config RPC to tfprotov5

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

None

[austinvalle]

Left a couple notes on naming/extra funcs to consider, but since there are more PRs coming for protov6, will approve to not block 👍🏻

[austinvalle]

This will be interesting to flip on, since it's likely providers will have no existing test coverage for generate config (since it's a TF core feature ATM), and it's currently an "all-or-nothing" approach 🤔 (and will likely not write test coverage for resources that don't customize this). Might put providers in a situation where they get bug reports for something that they weren't aware was being enabled for "all" resources.

I don't have a solution, just sharing an observation 😆

[austinvalle]

Thought from our recent planning meeting - scenario: SDKv2 provider server implements GenerateConfig, but the Framework provider server doesn't. What happens in core?

This could happen if we didn't implement them at the same time (due to priorities), or because a provider doesn't bump both Go module versions at the same time

[austinvalle]

The more we talk about this, the more I think that this shouldn't be a temporary interface, rather being required / forcing a build error if all Go modules don't implement this RPC. This mirrors the GetResourceIdentitySchemas RPC, which we didn't choose a build error and ended up with unexpected downstream errors due to providers not implementing it across all provider servers

[austinvalle]

See https://github.com/hashicorp/terraform-plugin-go/blob/main/.github/CONTRIBUTING.md#temporary-interfaces-for-new-rpcs . I think we could argue this RPC falls under "core will always call it" because of that provider-wide capabilities flag

It's also interesting for any terraform-plugin-go implementations (like kubernetes manifest), this will need to be implemented there as well. That could be a blocker for adoption since it's provider-wide 🤔

[stephybun]

All interesting points, if we're making this a required interface should we wait for SDKv2 and Framework to have implementations of this ready before merging? My main concern is blocking the release of any other RPC additions in plugin go that might wrap up earlier like pluggable state store?

[austinvalle]

Yeah, good point 🤔, we can revisit the timing of RPCs merging into main when folks start to get closer to finishing the implementation. We could go with a "whoever finishes first approach" and just plan to separate the releases regardless.

We can revisit once folks start returning from holiday time off 👍🏻