fix: abort scenario where canary/stable service is not provided

[pjiang-dev]

fixes #4128

When introducing ping-pong support for Istio https://github.com/argoproj/argo-rollouts/pull/3371/files this PR removed validation for canary/stable service for rollouts when using DestinationRule. This caused a deadlock scenario when aborting a rollout that has a replica not ready:

1. The Istio reconciler won't update the DestinationRule because the ReplicaSet isn't available
2. The ReplicaSet cleanup logic is waiting for the traffic routing to complete: "delaying destination rule switch: ReplicaSet my-srvc-64b664b6f not fully available"
3. The rollout gets stuck in "Progressing" state and cannot abort

With this fix:

1. Check only relevant ReplicaSets: Instead of checking all ReplicaSets for availability, only verify ReplicaSets that will actually receive traffic (stable and canary hashes), ignoring irrelevant ReplicaSets that don't impact traffic routing. This will allow aborts to happen. Abort clears the canary hash with the unavailable RS.
2. Return nil instead of error: When unavailable ReplicaSets are detected, return nil to delay the DestinationRule update rather than returning an error, allowing the reconciliation process to continue and enabling proper abort functionality.
3. Added tests for these scenarios where no canary/stable service are defined and there is an abort

This will fix both scenarios for manual abort or progressDeadlineAbort for rollouts.

kubectl argo rollouts get rollout my-srvc -n my-namespace 
Name:            my-srvc
Namespace:       my-namespace
Status:          ✖ Degraded
Message:         RolloutAborted: Rollout aborted update to revision 2
Strategy:        Canary
  Step:          0/3
  SetWeight:     0
  ActualWeight:  0
Images:          nginx:alpine (stable)
Replicas:
  Desired:       3
  Current:       3
  Updated:       0
  Ready:         3
  Available:     3

NAME                                 KIND        STATUS        AGE  INFO
⟳ my-srvc                            Rollout     ✖ Degraded    34m  
├──# revision:2                                                     
│  └──⧉ my-srvc-64b664b6f            ReplicaSet  • ScaledDown  33m  canary,delay:passed
└──# revision:1                                                     
   └──⧉ my-srvc-7bfd4dd8b6           ReplicaSet  ✔ Healthy     34m  stable
      ├──□ my-srvc-7bfd4dd8b6-5tzqg  Pod         ✔ Running     34m  ready:1/1
      ├──□ my-srvc-7bfd4dd8b6-c2rlx  Pod         ✔ Running     34m  ready:1/1
      └──□ my-srvc-7bfd4dd8b6-sltlg  Pod         ✔ Running     34m  ready:1/1

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
• The title of the PR is (a) conventional with a list of types and scopes found here, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
• I've signed my commits with DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My builds are green. Try syncing with master if they are not.
• My organization is added to USERS.md.

[github-actions]

Published E2E Test Results

  4 files    4 suites   3h 16m 18s ⏱️
115 tests 106 ✅  7 💤 2 ❌
462 runs  432 ✅ 28 💤 2 ❌

For more details on these failures, see this check.

Results for commit 515799e.

♻️ This comment has been updated with latest results.

[github-actions]

Published Unit Test Results

2 311 tests   2 311 ✅  3m 1s ⏱️
  129 suites      0 💤
    1 files        0 ❌

Results for commit 515799e.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud