Track if backup codes have been verified

[iandunn]

One of the commits from #245 was reverted in 03ab804. This achieves the same goal as that commit, but in a way that doesn't have the side-effects that it did.

It takes a similar conceptual approach to #221, where it keeps track of whether or not the codes have been verified. That can't be done in BackupCodes, though, because the state would get lost when clicking Back. It also can't do it in local storage, since that wouldn't persist across browsers.

This approach keeps the state in Main so that it won't get lost, but it ultimately relies on the database as the canonical source of truth. The user record is refreshed after saving the codes so that the system knows the user has them, but it also has the state of whether or not they've verified them. The combination of those two lets us achieve the original goal but without the side effects.

I also added some defensive code to the Password component. That's not necessary for the main fix here, it's just related because the need for it was exposed by the previous bug.

Testing

1. Start without backup codes saved for the user
2. Visit the Backup Codes screen. Codes will automatically be generated and saved for the user.
3. Click Back. The Backup Codes status will show that it's active
4. Click on Backup Codes, and you'll see the Manage screen. Before the fix, you would have seen the Setup screen and new codes would have been saved

Also test that flow but with clicking Finished, and do some general tests to make sure there aren't any side-effects.

[StevenDufresne]

This is a better solution that doesn't appear to impact the user experience 👍 .

[renintw]

LGTM 👍 Thanks for the fix!

[renintw]

Just add some notes about my testing process for the logic here for future reference.

Initially, I thought of setting this value to false during testing.
And setting this part to true only when the Back button on the backup-codes screen is pressed.

However, there are two issues with this approach:

1. Currently, within ScreenLink, we can't determine which screen the Back button is pressed from.
2. Even if we could determine that, since the value is set to true only when the Back button on the backup-codes screen is pressed, this condition with ! backupCodesVerified would be true again when the user exits the account screen (when Main is unmounted) and returns to the account screen, leading to another unexpected re-generation of backup-codes.

So, the current logic is that every time the ScreenLink component is pressed, it will execute setBackupCodesVerified( true );. I believe this is an acceptable compromise, especially since this workaround was put in place primarily due to the side-effects of two-factor/#507.