Revisit RequireConfirmedEmail behavior/design

[HaoK]

Related: aspnet/Templates#832 (comment)

We also should rationalize if we need a concept of AccountConfirmation which a more generic class what EmailConfirmation is today.

• Should this flag affect external login providers, or only password flows?
• Do we need a AccountDisabled flag that replaces this for use in ExternalSignIns?

Do we need to do anything here for 2.0 or can this wait til 2.1?

@ajcvickers @blowdart

[Ponant]

You/we can solve this issue in one shot by doing the following, as we discussed last time.

Drill into these issues as you linked them to other issues opened by other devs
https://github.com/aspnet/Identity/issues/1265
https://github.com/aspnet/Identity/issues/1276

All these issues will be closed at once. I am not sure this is what @blowdart proposed but to me it is solid and logical. At least I implemented in this way by rewriting parts of the SignIn.
I would vote for 2.0 because it is time to do it in my opinion and also because it will offer a cleaner flow for the Identity Service that has been excluded from 2.0.

[blowdart]

It's not going to be 2.0, because we simply don't have the bandwidth

[Ponant]

Reminder: The culprit is here
https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNetCore.Identity/SignInManager.cs#L747

1. PreSignInCheck which checks for pwd but called by ExtrernalLogin. Solution--> break it into pieces in order to call only the necessary pieces (it is called 4 times in SignInManager)
2. SignInResult.NotAllowed--> split into email and phone confirmation flags, to become more granular

[HaoK]

Tracked via #8356