Increase security with single failure for login, password, and tfa

Moving this to 2.x since this is a dependency for if we want to decorate the user.auth service in 📌 Decorate the user.auth service Fixed

Biggest issues I'm seeing right now are implementing this in a way that is reasonable and secure, and providing a reasonable UX.

Method 1) Request username and than show either show password or password + tfa fields
This ends up causing a User Enumeration vulnerability for users with TFA enabled, just entering a username with invalid password will create a page that requests a token, which by its existence confirms the account exists and has TFA enabled. Accounts without TFA would not be subject to this issue.

Method 2) Use a single form, prompt for username+password, validate login, determine how we render.
If successful and user doesn't require TFA log user in.
If unsuccessful auth add a TFA form and provide no feedback on success/failure until form is submitted again.
If auth is successful and user requires TFA add a TFA form and validate.

This mitigates the User Enumeration compared to the first scenario, though I'm not sure it fully eliminates it, while at the same time fully solving this issue. This is due to the fact that we may need to render different plugins based on the tokens a user has configured.

In the case of a user without TFA if they use the wrong password we are going to provide them a bit of bad UX with a token field that may be confusing. We also need to determine what to render on the page. If we render the same content always (without consideration of a valid users configured tokens) than we have essentially not implemented this feature, because we are still providing feedback (by page design) that the failure was a password fault, even if we used a random display that is still feedback to the fact the password was invalid. If we used the actual configured tokens for the user that returns us to an enumeration fault.

If we render the form correctly when the user auth is successful that again returns us to not having actually implementing this feature.

Given the concerns above, it may be best for this to remain as is. Moving to PNMI to allow others to provide implementation feedback in case I'm not realizing an alternative method of implementing this.