Migrate tfsdk package Config, Plan, and State into schema package

[bflad]

Reference: #76

These types are tightly coupled to Schema and Attribute handling and migrating them will allow for future enhancements with Attribute plan modifications and validations to reference these types without an import cycle.

[kmoe]

I think this is fundamentally the right idea, because our Config, State, and Plan types are "schema-rich" - they are the abstraction the framework creates to marry the concepts of "value that comes over the wire from Terraform" and "user-defined schema" to provide a way of accessing those values as values of the schema type.

The validation work adds an irreducible dependency in the other direction, since the schema validation takes the config (and therefore schema) as one of its inputs.

The only way I see to resolve this inherent circularity would be to abstract the schema dependency from the Config type, so instead of

type Config struct {
	Raw    tftypes.Value
	Schema schema.Schema
}

you would have

type Config struct {
	Raw    tftypes.Value
	Schema elsewhere.Typer
}

where Typer is an interface Schema fulfills. Then you'd have to use dependency injection to fill that with the actual Schema type when creating the Schema-specific version of the validation functionality inside the schema package. I don't think this is really feasible given the shape of the APIs we want to offer.

Here's the package dependency graph of main right now:

Graph of branch f-schema-validation:

And finally, what happens if you move the proto6 functionality that depends on schema into schema (isolating the circular dependency, so we can ignore proto6):

I therefore think this PR is the right idea, but we should rename the schema package if we do this, so we don't end up with types schema.Plan, schema.Config, etc, which are semantically off.

The package name should be something that captures the concerns we've grouped together here, i.e. the resource values Terraform sends to us in the protocol, in a "schema-rich" form. I'm struggling to think of anything less abstract than values, vals, tfvals...

[paddycarver]

I agree with @kmoe that an interface is likely not the route we want here.

I'm wondering if bringing the schema and internal/proto6 packages into the tfsdk don't resolve this. I think, fundamentally, we're no longer able to separate the package that describes the shape of resources (schema) from the package that describes uses values for those resources, because the schema package itself uses those values. schema is going to, unless we contort ourselves weirdly, require access to Config, State, and Plan. and Config, State, and Plan are going to need access to the Schema type to understand the data they're holding. So I think we can't escape having them in the same package. I'm not sure what we gain from keeping those types separate from the resource, data source, and provider interfaces at that point, or why we'd want them separate from the request/response types or the Serve function. I think the Schema type is just more central to the framework than we originally anticipated when we separated it into its own package.

Benefits:

• Our nested attributes code can be simplified, unexporting many implementation details that were exposed so Serve/proto6 could get to them.
• If the package gets too large, we can still start drawing semantic boundaries between packages that make sense, and it may be easier to see those boundaries without other boundaries standing in the way.
• I worry that combining Config/Plan/State with Schema in a separate package of their own will muddy the distinction between describing the shape of a resource/data source/provider and accessing values of that shape, for little gain.

I have a quick sketch of this PR with everything moved to tfsdk, and it compiles (no import cycles) and tests pass, so I think this strategy would work.

[bflad]

#77 has the version of this with schema/* -> tfsdk/ and internal/proto6.Schema()/internal/proto6.Attribute() -> tfsdk/

[kmoe]

Happy to close in favour of #77

[bflad]

We have opted for #77 -- closing this PR.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.