fix: apply scheduling strategies by TID with TGID fallback

[thc1006]

This patch make the plugin apply a scheduling strategy by the thread id (TID), with a fallback to the thread group (TGID).

Why

The lookup was inconsistent: priority was resolved by task.Tgid but the custom time slice by task.Pid, so the same strategy behave differently between the two path. Once the decision maker start to key node-policy strategies by TID (companion: Gthulhu/Gthulhu#135, which close Gthulhu/Gthulhu#132), the custom time slice only reach the group leader, not the worker thread the policy target.

The change

Both applySchedulingStrategy and getTaskExecutionTime go through one lookupTaskStrategy: prefer an exact thread (TID) match, then fall back to the thread group (TGID). A node policy (keyed by TID) bind to the exact worker thread; a Pod policy (keyed by the container leader PID) still reach every thread of the group through the fallback; and when both exist for one thread, the TID-specific rule win.

Only a boost jump the queue

A strategy now only jump the run queue (Deadline 0) when it actually boost, i.e. Priority > 0. A Priority == 0 strategy still get its custom time slice, but keep normal vtime ordering instead of being forced to the front. Before, any match set Deadline 0 regardless of priority. TestSliceOnlyStrategyDoesNotJumpQueue cover this.

About the Pod slice behavior

Because priority and slice now share the lookup, a Pod policy's custom time slice now apply to every thread of the group, not only the leader. This is on purpose - priority already fan out to the whole group via task.Tgid, so the slice is now consistent with it. TestPodPolicySliceAppliesToAllGroupThreads pin this so nobody narrow it back by accident.

Known limitation

The strategy map is keyed by a bare PID with no TID/TGID discriminator. So if a node policy's target thread happen to be its group leader (TID == TGID), the sibling thread of the same group also resolve it through the TGID fallback. For a non-leader target (the common worker / poll thread) it stay thread-local. A precise fix need the decision maker to carry the match kind (TID vs TGID); tracked as a follow-up.

Two more fixes

GetChangedStrategies used to drain running changed/removed event queues that UpdateStrategyMap appended to, under a read lock. Two bugs:

1. Concurrent callers race on the slice → now take the write lock.
2. A strategy removed then re-added before a drain appeared in both the changed and removed lists; the kernel consumer applies all changes then all removals, so it ended up deleted. It now diff the current desired set against a snapshot of the last applied set, so a key is only changed OR removed, never both (TestGetChangedStrategiesCoalescesRemoveThenReadd).

go test -race ./plugin/gthulhu/... is green.

Signed-off-by: thc1006 84045975+thc1006@users.noreply.github.com