Update BrightnessSynchronizer Logic

There was an error where if two auto-brightness changes came in quick
succession, the first could be treated as a user-initiated brightness
change.

1. First float change comes in: Xf
2. We write the brightness to the int-setting: Xi
3. Second float change comes in: Yf
4. Notification of the Xi change comes back to us and because X is
   different from Y, we treat it as a user-change.

The result of this is that auto-brightness learned from these erroneous
"user inputs" and both the short and long term model get affected
negatively for the user.  Often manifesting in brightness learning to
be too low.

The quick succession changes can happen in various situations, but
were most prominent on startup before and after a valid lux is read.

The fix is the revamp the data synchronization algorithm we use in
BrightnessSynchronizer to have updates + confirmation callback be
treated as an atomic operation before executing any other updates
that come in.  In the example above, that means we run (1) (2) and (4)
before handling the new update found in (3).

Fixes: 227483176
Test: Manually verify through debug logging.
Test: atest BrightnessSynchronizerTest
Change-Id: I93856fd74e50bcda04e88a7b7e736e02faa76c8e