Treat empty strings as null in NestingSet objs when looking for dynamic blocks in AssertObjectCompatible

[jbardin]

The Legacy SDK cannot handle missing strings from objects in sets, and
will incorrectly insert an empty string when planning the missing value. This
subverts the couldHaveUnknownBlockPlaceholder check, and causes
errors when dynamic is used with NestingSet blocks. We can treat
empty strings as null strings within set objects to avoid the failed
assertions.

We don't have a separate codepath to handle the internals of
AssertObjectCompatible differently for the legacy SDK, but this condition
should not be reached by new providers.

Fixes #25600

[codecov]

Codecov Report

Merging #26638 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted Files	Coverage Δ
plans/objchange/compatible.go	68.50% <100.00%> (+0.31%)	⬆️
terraform/eval_apply.go	74.62% <0.00%> (+0.60%)	⬆️

[mildwonkey]

Looks good to me; it wasn't clear but (writing this out for posterity's sake) based on our discussion it's ok to return a null value here in the plan even if the set value is an empty string, because terraform will honor that during apply.

[jbardin]

Yes, this code is only used for raising an error with AssertObjectCompatible, and does not effect the actual values themselves. I also realized that while this does allow a specific change that could be more strictly caught as an error, it should not effect future providers as they are prevented from returning the incorrect value in the first place.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.