sched_ext and proxy execution no longer mutually exclusive

Andrea Righi has posted patches that let proxy execution work with sched_ext, ending a build-time mutual exclusion that forced distributors to pick one feature or the other.

Proxy execution lets a task blocked on a mutex donate its scheduling context to the lock owner, so the owner runs with the waiter's eligibility and classic priority inversion is reduced. sched_ext drives dispatch through BPF programs and its own dispatch queues (DSQs). A proxy handoff can put a task on the CPU that the BPF scheduler never admitted or ordered, so kfuncs and internal bookkeeping can see a "current" task that does not match what the BPF side believes is running.

That mismatch is why CONFIG_SCHED_PROXY_EXEC and CONFIG_SCHED_CLASS_EXT could not be enabled together. The restriction is awkward for anyone who wants a single kernel image and runtime choice of scheduler features.

The design makes proxy support optional per BPF scheduler. A scheduler that sets SCX_OPS_ENQ_BLOCKED keeps mutex-blocked donors runnable and receives them on enqueue with SCX_ENQ_BLOCKED, so BPF decides whether, where, and in what order to dispatch each donor. The core then walks the mutex-owner chain and, when needed, moves the donor's scheduling context to the owner's runqueue before the owner executes. Schedulers without the flag keep the old behavior: blocked sched_ext tasks take the normal block path and are not retained as donors.

Related core fixes cover false migration-disabled warnings when only a blocked scheduling context moves, CFS bandwidth tick checks that must look at the selected donor rather than the physical current task, and races when proxy execution changes on-CPU state during remote DSQ handoffs. Selftests cover same-CPU and cross-CPU priority inversion with the flag on and off, and the scx_qmap demo scheduler gains a switch to opt in.

The work builds on earlier proxy-execution efforts by John Stultz and is aimed at the sched_ext tree for the 7.3 cycle.