Ensure all sdkv2 test providers have an id and an update method

[VenelinMartinov]

This change tweaks the EnsureProviderIsValid method in pulcheck to always give resources an id property and ensure they pass the TF validation with respect to Update methods.

Previously we'd run into trouble with TF validation when a resource needs an Update and doesn't have one or it doesn't need an Update and has one. The rules are non-trivial so I've opted to just make all resources need an Update and ensure they have one.

[VenelinMartinov]

This change is part of the following stack:

• Ensure all sdkv2 test providers have an id and an update method #2723 ◀
  • Add SDKv2 detailed diff set tests for top-level ForceNew #2724
    • Refactor SDKv2 non-set detailed diff tests #2725
      • Add SDKv2 Detailed Diff tests for list replacements #2735
        • Add SDKv2 Detailed Diff tests for lists with many elements #2736
          • Add SDKv2 Detailed Diff tests for Computed properties in sets #2740
            • Refactor SDKv2 set detailed diff tests to correct files #2741

_{Change managed by git-spice.}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.64%. Comparing base (5b45441) to head (0f1206a).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2723      +/-   ##
==========================================
- Coverage   69.64%   69.64%   -0.01%     
==========================================
  Files         301      301              
  Lines       38726    38726              
==========================================
- Hits        26971    26969       -2     
- Misses      10237    10240       +3     
+ Partials     1518     1517       -1     

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

[iwahbe]

I'm not sure I understand this change. We believe that resourceNeedsUpdate is wrong, but are still using it?

Where does this cause us problems?

[iwahbe]

Why do we need to add the if !resourceNeedsUpdate(r) { ... } block if we remove the conditional.

[t0yv0]

Sounds like EnsureProviderValid is actually doing something like populating defaults into the resource schemas. Adding update_prop is really non-intuitive to callers, why would it do that?

What if we just inlined and got rid of EnsureProviderValid and made the resource schemas in every test realistic, with comments e.g. if update_prop is added then why it's added?

[VenelinMartinov]

Yeah, that's a bit of a weird one. Turns out Terraform is not consistent with its own rules and some valid schemas can not pass validation.

We call InternalValidate on all schemas in pulcheck.EnsureProviderValid. That function also fills in some reasonable defaults. Unfortunately, the TFInternalValidate rejects some valid schemas or if the rules from InternalValidate are enforced the schemas fail at runtime. Consider this:

	"test": {
		Type:     schema.TypeSet,
		Optional: true,
		ForceNew: true,
		Computed: true,
		Elem: &schema.Resource{
			Schema: map[string]*schema.Schema{
				"nested": {
					Type:     schema.TypeString,
					Optional: true,
				},
				"computed": {
					Type:     schema.TypeString,
					Optional: true,
					Computed: true,
				},
			},
		},
	},

This schema has all its top-level properties as ForceNew, so according to InternalValidate its Update is redundant. This is not correct, as a user might only update the nested property which is not ForceNew, and doing that fails during runtime.

This behaviour is very non-intuitive and took me a while to figure out that TF Validation has a bug here. We could say that each person who writes a test is responsible for dealing with this and working around this but that seems harder.

I've instead opted to work around the whole mess by adding an Optional update_prop to all schemas, which makes sure that Update is necessary. Having extra properties in the schema seems like the lesser evil here. I'll leave a note with the explanation.

[t0yv0]

Thanks for the explanation, this makes sense! At the very least this needs to be a comment I think on the "update_prop" - that is it's a no-op prop added to make InternalValidate pass.