Add configurable affinity_mode for egress pod selection

[abhisheksingh-R41]

Problem

The current StartEgressAffinity scores idle pods at 0.5 and busy pods at 1.0. Combined with MaximumAffinity=1 in the psrpc client, this causes a staircase distribution: as soon as a pod accepts its first job it scores 1.0 and wins all subsequent jobs via the short-circuit, until its CPU budget is exhausted. The next pod then starts filling, and so on.

The existing source comment acknowledges this is intentional:

"if this instance is idle and another is already handling some, the request will go to that server. This avoids having many instances with one track request each, taking availability from room composite."

This is the right behaviour for mixed fleets (Track + RoomComposite). However for a TrackEgress-only fleet the packing strategy provides no benefit and actively hurts KEDA/HPA scale-out — newly provisioned pods start idle at 0.5 and always lose to already-busy pods until those pods saturate.

Solution

Add a configurable affinity_mode field to ServiceConfig. The default (pack) preserves existing behaviour exactly — zero change for current deployments.

Mode	Affinity scoring	Best for
pack (default)	idle=0.5, busy=1.0	Mixed fleet (Track + RoomComposite)
spread	CPU-proportional; idle=1.0 → wins immediately	Single-type fleet (TrackEgress only)
type_aware	RoomComposite/Web prefer idle pods; Track/Participant spread by CPU load	Mixed fleet with smarter routing

How spread works

• Idle pods return AvailableCPUFraction() == 1.0 → hits MaximumAffinity=1 and wins immediately (same speed as current busy-pod short-circuit).
• Busy pods return their remaining CPU fraction (e.g. 0.6) → client waits ShortCircuitTimeout=500ms and picks the least-loaded pod.
• Result: jobs distribute evenly across all pods rather than packing sequentially.

Changes

• pkg/config/service.go — adds AffinityMode string \yaml:"affinity_mode"`toServiceConfig`
• pkg/stats/monitor.go — adds AvailableCPUFraction() float32 (wraps existing getCPUUsageLocked; idle returns 1.0, busy returns available/total)
• pkg/server/server_rpc.go — replaces StartEgressAffinity with mode switch; adds isHeavyEgressRequest helper
• pkg/server/server_rpc_test.go — table-driven unit tests for isHeavyEgressRequest covering all 5 request types

Backwards compatibility

• affinity_mode defaults to empty string which falls through to default: case — identical to current pack behaviour.
• No changes to existing config parsing, prometheus metrics, or admission logic.

[abhisheksingh-R41]

@frostbyte73 @milos-lk — would appreciate a review when you get a chance. This adds a configurable affinity_mode to address staircase distribution in single-type (TrackEgress-only) fleets. Default is pack so existing deployments are unaffected.

[biglittlebigben]

Could you provide more information about the motivation for handling track/participant requests differently? The main motivation for the current scheme is related to autoscaling, particularly down scaling: since draining an instance can take a long time, we want to make sure that the instance most likely to get terminated on a down scale event is the one with the east requests (ideally 0).

If we were to take a patch to adjust the behavior, most extensive unit tests would be needed to ensure no regression over time.