Container Apps Revision Strategy

[wbreza]

Summary: Implement revision-based deployment strategy for Azure Container Apps with traffic splitting and gradual rollout capabilities.

Acceptance Criteria:

• Deploy new version as Container Apps revision
• Gradual traffic routing to new revision
• Configurable traffic splitting percentages
• Health check integration before traffic shift
• Revision naming and labeling strategy
• Rollback to previous revision capability
• Integration with Container Apps revisions API

[weikanglim]

My current thinking is that we will want to support these in a way that feels natural and doesn't deviate too much from what is currently documented as best practices for container app, i.e. blue-green deployments.

Right now, azd is promoting an "image upsert" strategy, where a dummy image alongside with desired container app properties is created in azd provision the first time, and azd deploy is done separately to mimic a smallest possible image update operation. This works great in simple deployment scenarios.

Looking forward to production scenarios, if traffic splitting, multiple active revisions were supposedly supported by azd deploy, azd provision attempts would end up resetting the state of the container app back to a single revision mode.

This would happen since the source of truth is actually split across the Bicep files, and possibly this new proposed YAML definition we are thinking about.

If we are also thinking about production scenarios, being able to perform both image + app configuration (environment variable) updates in a single revision would be quite important.

I have put out #5694 as an inspirational work on what this could look like moving forward.