Improve revision tracking system to better handle concurrent updates

Spun out from MIR-218 to focus specifically on improving how revision tracking works throughout the system.

Background

During investigation of a race condition in the app deploy process (MIR-218), we discovered that our current revision system isn't effectively preventing conflicts between concurrent updates due to how revisions are handled at different layers.

Current State

• We have a revision tracking system at the etcd and entity store layer
• The generated Go structs for higher level entity modeling do not have anything that retains revisions returned from the lower layers, so revisions get lost when manipulating objects at the higher layers
• The underlying system ignores revision constraints when the inputs do not set revision, so effectively the revision checking is disabled
• This means race conditions like the one in MIR-218 can occur without detection

Goals

• Figure out how we want to retain revision information at the higher layers so the revision tracking system can help us catch conflicts
• Design a strategy for plumbing revision data through the system layers
• Ensure revision checking is properly enabled and utilized
• Make the system more robust against race conditions

Questions to Answer

• How should we modify the generated Go structs to retain revision information?
• What's the best pattern for passing revisions through the higher-level APIs?
• Should revisions be mandatory or optional at different layers?
• How do we handle cases where revision conflicts are detected?

Acceptance Criteria

• Design approach for retaining revisions in higher-level Go structs
• Implement revision plumbing through the system layers
• Ensure revision checking is enabled and working
• Test that conflicts are properly detected and handled
• Document the revised revision tracking patterns