feat(multi-slb): use desired state operation for local service backend pool updater

[Liunardy]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Changes the local service backend pool updater to reconcile toward a desired state instead of applying incremental changes. Previously, each EndpointSlice change was turned into separate add and remove operations by comparing the previous and current slice, and those operations were replayed against the backend pool. This depended on the accuracy of a single previous-slice snapshot, could lose membership contributed by other slices, and could queue redundant or conflicting operations for the same pool.

Now each update carries the full set of node IPs a backend pool should contain, computed from all EndpointSlices belonging to the service. On every reconcile the updater reads the pool's current membership, compares it against the desired set, and applies the additions and removals needed to converge in a single update. Because the outcome is derived from live pool state rather than a remembered delta, reconciles are idempotent and self-correcting.

Updates queued for the same pool are collapsed so only the latest desired state is kept: an update matching what is already queued is a no-op and preserves any in-progress retry state, while a changed desired state supersedes the pending one. If an update is requeued after a failure but a newer desired state has since arrived for the same pool, the stale one is dropped, carrying forward any throttling delay so ARM back-pressure is still respected.

As a result, update events and success metrics are emitted only when a pool actually changes, and a Service can no longer receive both a failure and a retry event for the same update. The reconcile path is also hardened against backend addresses that carry no IP.

Which issue(s) this PR fixes:

Part of #10270

Special notes for your reviewer:

Design doc: #10417
Documentation for topics/multislb: #10648

Follow-up to #10635, which deferred the desired-state operation model to this PR. It builds on #10635 and should be reviewed on top of it and merged only after #10635 has merged.

Does this PR introduce a user-facing change?

feat(multi-slb): the local service backend pool updater now reconciles each backend pool to the full desired set of node IPs instead of applying incremental add/remove changes. A success event and metric are recorded only when an update is successfully applied to a backend pool, and a Service no longer receives both a failure and a retry event for the same update.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Liunardy

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Liunardy]

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

[kubernetes-prow]

@Liunardy: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cloud-provider-azure-e2e-ccm-vmssflex-capz	423e216	link	true	/test pull-cloud-provider-azure-e2e-ccm-vmssflex-capz
pull-cloud-provider-azure-e2e-ccm-capz	423e216	link	true	/test pull-cloud-provider-azure-e2e-ccm-capz

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[kubernetes-prow]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.