Explicitly allow/deny als based brightness tuning
Explicitly allow/deny als based brightness tuning

Whether automatic brightness tuning is allowed to take place is
determined from 3 state variables (ongoing brightness fade type,
current and target display state). The order in which the state
change notifications are executed is not strongly defined and
some situations the display backlight is turned off without using
fade to black animation. This can lead to unwanted triggering of
als brightness tuning for example during in-call proximity blanking.

Use explicit condition for allowing/denying als brightness tuning
and set it directly from the main display state machine. This avoids
glitches resulting from timing of asynchronous state change handling.

Switch current and target display state tracking within display module
to use input triggers. The differences to using output triggers are
a) callbacks see unfiltered data - does not matter since the datapipes
   in question are not filtered
b) initial state is not automatically fed to callbacks - does not matter
   since change from undefined display state to on/off happens from the
   display plugin, after registering the trigger callbacks
c) the input triggers are executed before output filters - the conditions
   within display plugin are evaluated before other related mce logic

[mce] Explicitly allow/deny als based brightness tuning. Fixes JB#30090

mikkoharju/mce,mlehtima/mce,mlehtima/mce,maikelwever/mce,spiiroin/mce,spiiroin/mce,spiiroin/mce,mikkoharju/mce,spiiroin/mce,mlehtima/mce,android-808/mce,mikkoharju/mce,android-808/mce,kimmoli/mce,mikkoharju/mce,maikelwever/mce,kimmoli/mce,android-808/mce,android-808/mce,maikelwever/mce,mlehtima/mce,maikelwever/mce,kimmoli/mce,kimmoli/mce