[Bug Report]: v0.9.0 breaks deployments with existing Storage Accounts (deployed with CARML <= 0.8.0)

[zydio]

Describe the bug

Release 0.9.0 introduced support for SFTP (and NFSv3) for Storage Accounts.

There are two problems:

1. This is a Breaking Change and this is not advertised in the release notes
2. This is a Breaking Change and makes it impossible to successfully run a deployment including existing Resource Groups that were first deployed with BICEPs using CARML <= 0.8.0

Looking in the repo history, this change comes from PR #2514 , which is erroneously marked as New feature (non-breaking change which adds functionality)

Regarding point 2, if you have deployed a Storage Account with any set of parameters with CARML <= 0.8.0, and you try to run a deployment again of the same BICEP with CARML >= 0.9.0 you get a BadRequest error with message The property 'isNfsV3Enabled' was specified in the input, but it cannot be updated as it is read-only. For more information, see - https://aka.ms/storageaccountupdate" and the deployment fails.

This is almost probably going to happen with isSftpEnabled too, for the same reason (can only be enabled when creating the storage account and not modified afterwards).

This might be an ARM (server side) issue: a parameter of 'isNfsV3Enabled: false' should be treated as 'isNfsV3Enabled' not being provided, given that the result is the same, and should not complain about an update to a read-only property.
For isSftpEnabled it should be the same.

New versions of the BICEP modules in stable releases should be backward compatible with existing deployments executed with old versions of the BICEP modules.

To reproduce

1. Deploy a Storage Account with any set of parameters with CARML <= 0.8.0
2. Run a deployment again of the same BICEP with CARML >= 0.9.0, it will fail

Code snippet

No response

Relevant log output

{
    "status": "Failed",
    "error": {
        "code": "AccountPropertyCannotBeUpdated",
        "message": "The property 'isNfsV3Enabled' was specified in the input, but it cannot be updated as it is read-only. For more information, see - https://aka.ms/storageaccountupdate"
    }
}

[zydio]

I see this has been addressed in #3290 but not yet included in an official release, so I'm closing this issue.

[davidkarlsen]

Hmm, I still get this with storage.storage-account:0.5.1283