Container App Revisions become unmanageable after updates (via API or portal)

Container Apps Reports Timeout on LRO despite apparently actually deploying and starting the containers in the revision.


API Call returns:
```
Message="Failed to provision revision for container app 'acctest-capp-220531111719259950'. Error details: Operation expired."
```

The revision being “created” is the `rev4` noted displayed as `Provisioned`, and the container is started successfully as shown in the App Insights log entry:

```
“[REDACTED]“,RestAPI,,,"5/31/2022, 10:27:29.835 AM",,,"5/31/2022, 10:26:45.775 AM","1653992805.77502"," * Running on all addresses (0.0.0.0)",stderr,F,"docker.io/jackofallops/azure-containerapps-python-acctest:v0.0.1","acctest-capp-220531111719259950--rev4-6779d76698-6xlmx",5aa611e0a9b2d86717621376de2336d6a21e43fbe6e677189c2828ea4098869b,"11f5c016-0ac7-4a67-b21a-488523b502c0","acctest-cont-220531111719259950","acctest-capp-220531111719259950",,"agreeableground-ab0a055d","ContainerAppConsoleLogs_CL",
```

However, the service reports `"provisioningState”: “Failed”`.

The Update configuration (specifically a configuration containing the minimum required properties plus a revisionSuffix), when sent as a Create operation, works correctly. Additionally, if it is the _first_ update to a newly created resource, it also works correctly. If applied as a subsequent update, it fails and the service cannot be updated further, even via the Portal, e.g.


API Version: `2022-03-01`

Start by reproducing the Container Apps update sequence against API version 2022-03-01: create the resource, apply the first update, then apply the subsequent revisionSuffix update. Compare the reported long-running-operation result with the revision's provisioning state; done means subsequent updates complete successfully instead of reporting an expired operation and leaving the resource unupdatable.

Written by the indexing model from the issue text.