RESTRICT AUTOMERGE: SettingsProvider: exclude secure_frp_mode from resets

When RescueParty detects that a system process is crashing frequently,
it tries to recover in various ways, such as by resetting all settings.
Unfortunately, this included resetting the secure_frp_mode setting,
which is the means by which the system keeps track of whether the
Factory Reset Protection (FRP) challenge has been passed yet.  With this
setting reset, some FRP restrictions went away and it became possible to
bypass FRP by setting a new lockscreen credential.

Fix this by excluding secure_frp_mode from resets.

Note: currently this bug isn't reproducible on 'main' due to ag/23727749
disabling much of RescueParty, but that is a temporary change.

Bug: 253043065
Test: With ag/23727749 reverted and with my fix to prevent
      com.android.settings from crashing *not* applied, tried repeatedly
      setting lockscreen credential while in FRP mode, using the
      smartlock setup activity launched by intent via adb.  Verified
      that although RescueParty is still triggered after 5 attempts,
      secure_frp_mode is no longer reset (its value remains "1").
Test: Verified that secure_frp_mode still gets changed from 1 to 0 when
      FRP is passed legitimately.
Test: atest com.android.providers.settings.SettingsProviderTest
Test: atest android.provider.SettingsProviderTest
Change-Id: Id95ed43b9cc2208090064392bcd5dc012710af93
(cherry picked from commit 9890dd7f)
(changed Global.SECURE_FRP_MODE to Secure.SECURE_FRP_MODE,
 needed because this setting was moved in U)
(removed static keyword from shouldExcludeSettingFromReset(),
 needed for compatibility with Java 15 and earlier)
(resolved conflict in resetSettingsLocked())
Merged-In: Id95ed43b9cc2208090064392bcd5dc012710af93