LSS: clear calling identity after permission check in checkCredential()

Since commit 3d5653e11e (http://ag/19599753), the call to
IStorageManager.unlockUserKey() after credential verification is done
directly by LockSettingsService, instead of indirectly by
IActivityManager.unlockUser().  IStorageManager.unlockUserKey() requires
the STORAGE_INTERNAL permission, which
LockSettingsService.checkCredential() doesn't have if it is called via a
Binder IPC from Keyguard (SystemUI).  This causes an exception that
crashes SystemUI.  (SystemUI has the ACCESS_KEYGUARD_SECURE_STORAGE
permission, and various other permissions, but not STORAGE_INTERNAL.)

Fix this by clearing the Binder calling identity in checkCredential()
just after the ACCESS_KEYGUARD_SECURE_STORAGE permission is checked.
This matches the very similar method verifyCredential().

The reason this bug wasn't noticed earlier is because the
above-mentioned CL happened to change IStorageManager.unlockUserKey() to
use @android.annotation.EnforcePermission instead of an explicit
permission check.  Unfortunately, the permission annotations have had a
bug that made them not actually work properly (b/241171714).  That bug
was just fixed yesterday, exposing this issue.

Test: can now unlock (via the UI) a device that has a PIN set.
Bug: 259401557
Change-Id: I5be5f086ac9405a9f3fb8d7641bd4a5cbb436208

services/core/java/com/android/server/locksettings/LockSettingsService.java

@@ -2081,9 +2081,11 @@ public class LockSettingsService extends ILockSettings.Stub {
     public VerifyCredentialResponse checkCredential(LockscreenCredential credential, int userId,
             ICheckCredentialProgressCallback progressCallback) {
         checkPasswordReadPermission();
+        final long identity = Binder.clearCallingIdentity();
         try {
             return doVerifyCredential(credential, userId, progressCallback, 0 /* flags */);
         } finally {
+            Binder.restoreCallingIdentity(identity);
             scheduleGc();
         }
     }