Revalidation: Prompted immediately after setting up 2FA

Describe the bug

The revalidation feature added in #529 is somewhat not ideal for a multitude of reasons, but one of the biggest pain points is that it's possible to setup a 2fa method and be prompted to revalidate instantly.

This occurs as there was code added to flag a session as being 2fa when the provider is enabled, but this is not when a provider is actually configured.

This is partly due to the way the user-interface works, with providers being able to be in 3 states for a user: Not Enabled, Enabled (but not usable), and Available (Enabled, and configured).

For some providers, such as TOTP, the flow can be either: Not Enabled -> Available or Not Enabled -> Enabled -> Available depending on whether the TOTP client is configured before enabling it, or after enabling it.

For some providers, such as Email or Dummy, there is no real Enabled state as they go directly from Not Enabled -> Available in all situations.

The way I've approached this on WordPress.org https://github.com/WordPress/wporg-two-factor/pull/186, is to set the 2fa settings after a provider is configured (for TOTP this is when they key is saved, and when a key is added for WebAuthn). This works for custom implementations like ours, but this doesn't translate directly to the Two-Factor plugin or how it's used.

The WordPress.org approach could potentially work however, if something like #526 was implemented, we could simply hook into the actions like ( provider.enabled OR provider.configured ) => Check if provider.is_available_for_user THEN set-as-2fa'd

Steps to Reproduce

1. Enable TOTP
2. Save (Note that the next page doesn't have it as checked, but that's irrelevant for us right now)
3. Wait 11 minutes (ie. Longer than the 10minute grace time, but shorter than the 2*$grace time of 20mins)
4. Setup TOTP
5. Reload the page (Do not re-check the checkbox for TOTP, do not update profile, reload)
6. Need to revalidate still, even though you JUST setup TOTP.

This is not very visible on the Two-Factor UI, and seems like an edge-case, but is much more visible with other providers or other plugins that use the Two-Factor API such as https://github.com/WordPress/wporg-two-factor eg: https://github.com/WordPress/wporg-two-factor/issues/173 https://github.com/WordPress/wporg-two-factor/issues/179 - The issue with the downstream project was partly a bug in the implementation there, but partly due to the above edge-case being triggered.

Screenshots, screen recording, code snippet

https://github.com/WordPress/two-factor/assets/767313/c06c4a78-82ed-4265-8c36-c49833757d92

Environment information

No response

Please confirm that you have searched existing issues in this repository.

Yes

Please confirm that you have tested with all plugins deactivated except Two-Factor.

Yes

Start in class-two-factor-core.php around the linked session-flagging code, then trace how providers move from enabled to configured and available. Reproduce the listed TOTP flow by waiting past the 10-minute grace period before setup. Done means configuring a provider prevents an immediate revalidation prompt, including for the provider states described in the issue.