Bridge should handle SchemaConfigModeAttr block attributes

[VenelinMartinov]

What happened?

During the work on #1725 I stumbled upon a panic in pulumi-azure: #1725 (comment)

TF SDK providers seem to have a special backwards-compatibility mode which allows specific resources to opt-in to a behaviour where they can distinguish between nil and empty collections - https://developer.hashicorp.com/terraform/plugin/sdkv2/guides/terraform-0.12-compatibility#computed-resource-attributes

This is not handled anywhere in the bridge and I suspect is the root cause for pulumi/pulumi-azure#1881 and the panic in #1725 (comment)

Example

const resourceGroup = new azure.core.ResourceGroup("test", {location: "westus2"});

const namespace = new eventhub.EventHubNamespace("test", {
    resourceGroupName: resourceGroup.name,
    sku: "Standard",
    networkRulesets: {
         defaultAction: "Allow",
         ipRules: [{
             action: "Allow",
             ipMask: "0.0.0.0/0",
         }],
     },
});

Output of pulumi about

tested with azure 5.69 which uses 3.77 of the bridge

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[VenelinMartinov]

Really hard to make progress here without sufficient tests. Very large room for regressions around this.

This would be easier with #1766 but it'd still need some work as TF JSON syntax might have limitations related to this issue: https://developer.hashicorp.com/terraform/language/attr-as-blocks#in-json-syntax

[t0yv0]

Can you try to specify a test a long the lines of

#1736

This should be doable but needs a little bit of thinking.

We can maybe check that ConfigureFunc receives the exact same data under Pulumi and TF over a range of auto-generated schemes with SchemaConfigModeAttr variability, and that it emits similar warnings - though comparing emitted warnings can get a bit gnarly and need some massaging.

[VenelinMartinov]

I had a quick go at it here #1784 and the create method seems to not get the same value between TF and pulumi but it might also be #1767.

I failed to repro #1767 in #1782, so not 100% sure what is happening. I'll have another go at all of this to sort it out next week.

Seems promising though

[t0yv0]

I'd like to pair early next week to have a look together. This is going to be interesting.