daemon: Limit KAuth backlighthelper calls to only one at a time
Plasma/6.1 cherry-pick for MR !342 (merged).
KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up.
This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then.
BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine.
In the same go, we make two related improvements.
Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started.
Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps.
Taken together, laptop brightness slider UX now seems decent.
(cherry picked from commit 033825d2)