Revision controller needs some cleanup/organization

[dprotaso]

/area API
/kind cleanup

Just revisited the revision controller after sometime. I figured I should write down my thoughts before I'm off on vacation starting now.

The revision controller is very fragile wrt. ordering of reconciling its child resources. Currently deployments are reconciled prior to pod autoscalers. Thus I've noticed:

1. Phases reading into the revision status may be reading stale data
   • The deployment phase looks at the Active condition, then after the PodAutoscaler phase may update it
   • MakePA looks at the revisions conditions to reconcile. Afterwards PA conditions are propagated to revision. Maybe this causes some churn?
2. Last Mark*() method wins - there's code in the PA phase to guard against overriding false conditions that it assumes the deployment phase has set
3. Re-ordering phases exposes assumptions:
   • deployment phase (when deployment is not found) marks the revision as 'Deploying' - but the PA phase doesn't.
   • test fixtures aren't accurate - ie. deployment was not ready when testing the steady state but still passed because of PA's ready state trumped all (see 2. above)

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[dprotaso]

/remove-lifecycle stale

/assign

[evankanderson]

/triage accepted