Revisit patchProposedNewForUnknownBlocks

[t0yv0]

2060 introduced a patch (patchProposedNewForUnknownBlocks) to objchange.ProposedNew algorithm vendored from OpenTOFU. This patch solves a usability issue with planning bridged provider update changes, specifically confirmed for sets with unknown elements. There are however some residual concerns whether this is the right fix. We should investigate if we can accomplished the desired goals in a way not involving patching.

Concerns:

• with the patch more unknowns are surfaced and pushed into provider code as part of PlanResourceChange; if provider authors write code against OpenTOFU/Terraform behavior they may ship code such as plan modifiers that does not expect these unknowns and will panic

• cross-testing against OpenTOFU becomes more difficult when the behavior deviates intentionally

Alternatives:

• Possibly the patch can be scoped tighter to sets

• Perhaps the problem can be solved at the outer Pulumi level, such as ensuring that unknowns from config are preserved at the corresponding positions in the plan, without disturbing the shape of the data passed to provider code

References:

• See TestUnknowns test suite and the "unknown for set block prop" test case

[VenelinMartinov]

I think this was not limited to sets - a few other test cases also had failures around https://github.com/pulumi/pulumi-terraform-bridge/blob/da2282374d3b7fb2227e526d2ecede9db7b8c03b/pkg/tests/schema_pulumi_test.go#L880

In pulumi we can have unknown objects, without the containing collection being unknown - it HCL this is perhaps not expressible (at least I have not found a way to express this) - we were not representing these diffs correctly before the patch and not showing a diff at all there.

[t0yv0]

I'm still concerned it's possible to write a provider that would panic under Pulumi with this but not under TF, but we can keep this around for a bit until we find a real example.