Allow RemovePodsViolatingInterPodAntiAffinity to act on preferred (soft) anti-affinity

[phoenix2x]

Is your feature request related to a problem? Please describe.

RemovePodsViolatingInterPodAntiAffinity only acts on requiredDuringSchedulingIgnoredDuringExecution. Preferred rules are silently ignored — the helper that pulls anti-affinity terms only reads the
required slice:

https://github.com/kubernetes-sigs/descheduler/blob/v0.35.1/pkg/utils/predicates.go#L344

In practice this means a Deployment with preferred pod anti-affinity (very common — services that want to spread across nodes for HA without risking unschedulable pods) can have all replicas land on one
node, and the descheduler will never rebalance them. We hit this on a real cluster: two replicas co-located on a Spot node, a clear preferred-rule violation, zero evictions over 9 days of dry-run.
Describe the solution you'd like

Same pattern that RemovePodsViolatingTopologySpreadConstraint already uses: an opt-in plugin arg. Roughly:

- name: RemovePodsViolatingInterPodAntiAffinity
  args:
    includeSoftConstraints: true   # default false — preserves current behavior

When true, GetPodAntiAffinityTerms would also return PreferredDuringSchedulingIgnoredDuringExecution terms.
Describe alternatives you've considered

Switched to topologySpreadConstraints with whenUnsatisfiable: ScheduleAnyway and the topology-spread plugin configured for [DoNotSchedule, ScheduleAnyway]. That works for our case, but topology spread isn't
a 1:1 substitute for anti-affinity in every scenario, and it's surprising that the two plugins behave so differently for soft constraints.
What version of descheduler are you using?

descheduler version: v0.35.1

Additional context

Happy to send a PR

[ricardomaraschini]

Let me see if my understanding of your report is correct: on RemovePodsViolatingTopologySpreadConstraint one can set the constraints configuration like so:

constraints: 
- DoNotSchedule
- ScheduleAnyway

DoNotSchedule is the default value if none is set. What you propose is that the RemovePodsViolatingInterPodAntiAffinity to support similar mechanics so one would be able to take PreferredDuringSchedulingIgnoredDuringExecution into account as well.

Something sorts of (to keep it similar to RemovePodsViolatingTopologySpreadConstraint):

constraints:
- RequiredDuringSchedulingIgnoredDuringExecution
- PreferredDuringSchedulingIgnoredDuringExecution

With RequiredDuringSchedulingIgnoredDuringExecution being the default if none is set. I think this is something we can have, let's hear what others think. If you prefer a risky approach you can go ahead and open a PR.