PodAutoscaler Active Condition should not affect Reachability

[dprotaso]

Fixes #14115

PodAutoscaler.Spec.Reachability was added a long time ago. Since then we've added a ScaleTargetInitialized condition to make it easier to know if we've scaled up from zero successfully - and this simplified various condition checks in the autoscaler etc.

Given that the PodAutoscaler's Active condition would toggle Reachability as @SaschaSchwarze0 pointed out.

I believe we don't need this circular logic - reachability should be set depending on the revision's routing state with the exception of failing to progress the deployment/start a users container.

[dprotaso]

Besides the feedback loop with active - reachability is also set to unreachable when the revision's deployment is known to be in a failure state (eg. progress deadline hit/imagepullbackoff)

I'm not sure that's necessary because it seems like reachability just affects scale bounds and indirectly KPA condition status

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.04% ⚠️

Comparison is base (ad5455e) 86.16% compared to head (6e94600) 86.12%.
Report is 42 commits behind head on main.

❗ Current head 6e94600 differs from pull request most recent head 1d9f1f5. Consider uploading reports for the commit 1d9f1f5 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #14309      +/-   ##
==========================================
- Coverage   86.16%   86.12%   -0.04%     
==========================================
  Files         195      196       +1     
  Lines       14702    14787      +85     
==========================================
+ Hits        12668    12736      +68     
- Misses       1729     1745      +16     
- Partials      305      306       +1     

Files Changed	Coverage Δ
pkg/reconciler/revision/resources/pa.go	100.00% <100.00%> (ø)

... and 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[SaschaSchwarze0]

@dprotaso I have taken your PR and tested the problematic scenario and simple scaleUp and scaleFrom/ToZero. Is all working. I can close my PR if consensus exists to go your route. Thanks for checking.

[dprotaso]

/assign @nak3 @ReToCode @skonto

cc @jsanin-vmw who's tackling a similar issue where pods don't scale down when we don't have metrics

[nak3]

One minor comment otherwise LGTM.

[nak3]

/lgtm
/approve

Thank you!

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dprotaso, nak3

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dprotaso,nak3]
• pkg/apis/OWNERS [dprotaso]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment