Make unblank and unlock via double tap work again

Legacy option to allow bypassing of lockscreen with doubletap was
broken.

Make it work again.

Also do not use raw numeric values to evaluate doubletap_gesture_policy.

[mce] Make unblank and unlock via double tap work again
Add helper functions for setting up configuration change tracking

Having helper functions for both reading initial values and installing
change notifiers allows builtin-gconf value tracking setup to be more
compact and readable.
Rewrite powerkey handler to allow more flexible configuration

Taking double powerkey presses in use caused unconditional delay for
single press handling. The actions that could be configured to be taken
were not be differentiated based on display state, which made it
impossible do one thing from display off and another one from display on.
And since static configuration was used, changes did not take effect
without restarting mce.

Make possible actions as small and simple as possible. Allow combining
them freely to choose actions taken. Use separate action combinations
depending on whether display is on or off. Execute common parts of
single and double press actions immediately when 1st powerkey press
is released.

Allow more flexibility for using custom dbus actions by allowing user
configured method call to be made instead of signal broadcast.

Use dynamic runtime changeable settings instead of static configuration
from ini-files and add options to mcetool for changing all of them.

Use the new functionality to:
- apply device lock when double press is made from display on
- unblank and hide lockscreen when double press is made from display off

[mce] Rewrite powerkey handler to allow more flexible configuration. Fixes JB#23653
Re-evaluate autolock if device wakes up from suspend

When display is automatically dimmed and then blanked there is a 30 second
grace period before tklock gets applied. Since the device most likely
also suspends soon after blanking the screen and we do not want to wake
up just to toggle the tklock state, the end of grace period is evaluated
when display is about to be turned on. This can cause ipc timing problems
if powerkey/doubletap is configured also to remove the tklock.

Also do opportunistic grace period end detection if the device wakes up
from suspend due to reasons that would not cause the display to turn on.
This should make it less likely that both lock and unlock happen at the
same time.

[mce] Re-evaluate autolock if device wakes up from suspend
Do not broadcast intermediate tklock changes over D-Bus

If mce side state machines oscillate between tklock on and off, it
can cause problems due to ui side trying to react to intermediate
states.

Use idle callback to delay sending of tklock state information so that
only the final tklock state is communicated outside mce process. Hold
a wakelock until the dbus ipc is actually made plus couple of seconds
to make it more likely for ui side to have time to process the state
change before device is allowed to suspend.

Also clear last send state when tklock change requests are made over
D-Bus. This way the state mce arrived at is always broadcast even if
the request ends up getting ignored.

[mce] Do not broadcast intermediate tklock changes over D-Bus
Set tklock if devicelock gets applied immediately after unblanking

If device is suspended, device lock might get applied at unblank time.
This in turn can leave the previously used application visible and
usable.

While the ideal solution would be to use iphb timer for locking the
device while still suspended, using heuristics at least denies full
access to application content if delayed device locking happens.

[mce] Set tklock if devicelock gets applied immediately after unblanking
Merge pull request #221 from spiiroin/jb23653_rewrite_powerkey_handler

Rewrite powerkey handler to allow more flexible configuration
Bump mce version to 1.37.0
Consider "undefined" device lock state equal to "unlocked"

When lipstick is restarted and device lock is not in use, ui ends
up showing lock screen instead of home. This happens initial
device lock = "undefined" is interpreted by mce as "locked".

Equate "undefined" device lock state with "unlocked" instead.

[mce] Consider "undefined" device lock state equal to "unlocked". Fixes JB#24138
Merge pull request #222 from spiiroin/jb24138_handle_undefined_device_lock_state

Consider "undefined" device lock state equal to "unlocked"
Bump mce version to 1.37.1
Block late suspend briefly when call state changes

The legacy call state tracking in mce uses only three states "none",
"ringing" and "active". Late suspend is allowed immediately after call
state changes to "active" - which for outgoing calls happens right
after the "call" button in ui is pressed. This can cause problems for
things like audio routing changes / dtmf playback that happens when the
call actually gets connected.

Block late suspend for 1 minute when call state changes to "active"
and 5 seconds for any other change in call state.

[mce] Block late suspend briefly when call state changes. Fixes JB#23614
Merge pull request #223 from spiiroin/jb23614_call_state_suspend_policy

Block late suspend briefly when call state changes
Bump mce version to 1.37.2
Do not autolock when device lock is applied due to lipstick startup

As a safeguard against leaving app ui visible due to lazy evaluation
of device lock timeout mce sets tklock too when device lock gets
applied right after powering up display. This logic misfires during
device bootup / lipstick restart and we end up showing lock screen
instead of device lock view.

Block autolocking from occuring for 1 minute after device lock state
makes transition away from undefined state i.e. when lipstick is
starting up.

[mce] Do not autolock when device lock is applied due to lipstick startup. Fixes JB#24842
Merge pull request #224 from spiiroin/jb24842_initial_device_lock

Do not autolock when device lock is applied due to lipstick startup
Bump mce version to 1.37.3
Improvements to sensor state handling when sensord is not available

If evdev source for als/ps is available amd sensord is not started, mce
ends up using sensor state that (possibly never powered up) sensors happen
to be reporting. This can break act dead mode totally if proximity sensor
default is covered (double tap does not work and alarms are not shown).

This fault was hidden for a while because sensord was erroneously started
in act dead too.

Add actual INITIAL state to relevant state machines instead of relying on
"sensord not available" IDLE states. This makes initial state transitions
to take place also in absence of sensord. This in turn is used to toggle
tracking_active flags for sensor reporting so that safe-guess-defaults
are used always when sensord is not alive regardless of whether we have
sensord data from sensord itself or from evdev sources.

[mce] Improvements to sensor state handling when sensord is not available. Fixes JB#24910
Merge pull request #226 from spiiroin/jb24910_no_sensord

Improvements to sensor state handling when sensord is not available
Bump mce version to 1.37.4