Fix KeyguardUpdateMonitor auth lifecycle issues

This is split into two high-level issues which together cause
strange auth behavior on keyguard:

============= Issue 1 =============
For fingerprint, auth ends when:
1) Success
2) Error

For face, auth ends when:
1) Success
2) Reject
3) Error

This change ensures that cancellation signal is set to null upon
any of these conditions, so that there is never an opportunity of
using a stale CancellationSignal.

Furthermore, do not invoke stale cancellation signal when
starting authentication. In the off chance the bug is re-introduced,
or if some other situation can cause a cancellation signal to be
non-null when keyguard requests auth again (e.g. bad state management
in keyguard), do NOT invoke the stale cancellation signal's cancel
method. The framework already handles this case gracefully and will
automatically cancel the previous operation.

============= Issue 2 =============

We have a runnable that's scheduled to run after X ms if
ERROR_CANCELED is not received after cancel() is requested. However,
there are various bugs around that logic:

1) shared runnable for both fp and face, leading to unexpected
   and incorrect state changes (e.g. face does not respond to cancel
   within X ms, both fp and face will go to STATE_STOPPED, even though
   cancel() was never requested of fp
2) Always remove and re-add runnable when requesting cancel() though
   it should never occur that cancel() is requested in close temporal
   proximity, it never hurts to have the correct timeout before
   resetting the state.

Bug: 195365422
Bug: 193477749
Test: manual
Change-Id: I3702f41c8af7e870798f19c43012a26281a6632a