Fix detect biometric logic.

Reverts the revert: Iea66d7782b3365dea827b854783aeddaa5c6699c
and updates the detect biometric logic to forward fix the CUJ.

[1] Never allow detectFingerprint or detectFace
to enter the device. DetectBiometric at most can
bring up the bouncer. It will never run the authenticate
path.

[2] When the temporary lockout state is reset, reset the fingerprint
listening state so that if SysUI was running detection,
SysUI will subsequently switch over to running authenticate.
If there's faceDetect running when lockout resets, we allow
faceDetect to complete running - if successful, it'll bring up the
bouncer where the user can either enter pin/pattern/password to
enter the device, or attempt face auth again by tapping the bouncer.

[3] Not directly related to detect but was causing a stuck
BIOMETRIC_CANCELLING_RESTARTING state: make sure to update
the biometric running state if the cancellation signal times out
and the biometric running state was BIOMETRIC_CANCELLING_RESTARTING.
Previously, the biometric state was only STOPPED when the cancellation
signal (framework didn't get back to SysUI in time) timed out

Note: There's a bug b/269743883 in the detect CUJ where if its
requested right after being cancelled, it can be stuck in the
CANCELLING_RESTARTING state. However, this will timeout after
3000ms and restart the fingerprint listening state afterwards.
This will be an issue until the framework bug is resolved to
send the cancellation confirmation to SysUI.

Test: atest KeyguardUpdateMonitorTest BiometricsUnlockControllerTest
Test: after the lockout, putting any finger on the FP sensor
will bring up the bouncer. after the lockout counter expires,
putting an unenrolled finger on the FP sensor will result in a FP error.
only enrolled fingerprints will allow the user to enter the device.
Bug: 269574598
Bug: 269769293
Bug: 269200614

Change-Id: Ic8f3d5b8b6a898a6d22f69c6e2ed4a3c24c61a6b