Ensure the keyguard is force-shown after a power off/on during unlock.

This fixes b/298450484, where unlocking an insecure keyguard and then near-instantly pressing the power button twice results in showing the lockscreen over the app/launcher. The race condition requires the device to be turned off and then back on within the time it takes the asynchronous startKeyguardExitAnimation call to return. This is easiest to reproduce if the double-tap camera launch gesture is disabled.

This bug was introduced by ag/24548147, which fixed a regression where the device would remain unlocked indefinitely after locking during unlock from the bouncer. That fix worked by checking isInteractive() and refusing to (incorrectly) set the keyguard to unlocked if the device was going back to sleep during an unlock.

Unfortunately, this CL's bug is caused by the fact that the keyguard is (correctly) not set to unlocked when it's locked during unlock. We have code that notices if the keyguard states don't match, and forces a call to setShowing(force=true) to rationalize these states. In this case, the fix resulted in us thinking that we were correctly already showing the keyguard. We actually are showing the keyguard UI, but we needed to tell WM again since the keyguardGoingAway call resulted in WM showing the app/launcher surface.

This CL keeps the fix from ag/24548147, and adds three additional checks that in theory, only skip short-circuit code and force the correct keyguard state:
- in doKeyguardLocked, refuse to short-circuit if the keyguard is going away. This makes sense - going away is being cancelled if we're "doing" the keyguard (showing it).
- in handleShow, force setShowingLocked if mHiding=true (the previous condition) OR if we're going away. mHiding is actually only true between the initial call to keyguardGoingAway, and the return of the async startKeyguardExitAnimation call. During the going away animation, mHiding is false, so we don't force setShowingLocked if we re-show the keyguard during that time.
- in exitKeyguardAndFinishSurfaceBehindRemoteAnimation, add to the ag/24548147 fix by also refusing to finish unlocking if mPendingLock = true. In the bug case, pressing power twice very quickly can result in isInteractive being true (since the screen turned back on), while a lock is still pending from the first power button press. If we're about to lock the keyguard again, it makes sense to not finish exiting the keyguard.

This is, as usual, as safe a fix as they come (we're forcing setting the correct state), but of course, that's what ag/24548147 did.

Fixes: 298450484
Test: disable camera gesture AND quintuple tap to call 911, set security to swipe mode, long-press lock icon and instantly double tap power as quickly as you can
Test: unlock from bouncer to an app, sleep during app launch animation, verify device locks
Change-Id: I02a25859eec3a7fb853001463dacb3730feb9c1d