Store implementations should have a way of notifying the UserManager

[tugberkugurlu]

Currently, a store implementation has no structured way to notify the UserManager on certain situations. For example, the e-mail uniqueness. This is currently achieved by the UserValidator service and this will work just fine for most of the situations but in a very niche race condition scenario, the application may end up putting duplicate e-mails into the system. E-mail uniqueness check should only be handled by the store itself when it's actually creating the user or altering an existing user's e-mail address. The user name is another similar case.

For these type of situations, the user store needs to be able to clearly communicate to the UserManager so that the right validation error messages would bubble up to the higher level.

[HaoK]

Not saying we are not open to changing the behavior, but the today if the store will blows up with an exception when this is detected. As you point out, since this is a niche race condition if the app just falls back to some kind of default generic error page, this could be reasonable, since a repeat attempt will most likely show the correct validation error

[rustd]

#296

[HaoK]

I think we just need to change the 3 write operations on IUserStore to return IdentityResult.

Create/Update/Delete. We'll also introduce a new IdentityError for Concurrency failed which will be the only error condition the stores currently would return.

@divega sound reasonable?

[divega]

@HaoK yeah, sounds reasonable.

BTW, this seems related to another conversation with @suhasj about the need to review and rationalize when we return IdentityResult across all the methods in the Identity stack. It sounds like nowadays we return it sometimes, maybe mostly when we do updates to the database? But perhaps there is a better principle we could extract from this, e.g. we do it for operations that have multiple possible outcomes besides success that client code could need to reason about without catching and swallowing exceptions.

[HaoK]

Its actually pretty simple right now, anything operation that results in a 'write' operation (ends up calling Create/Delete/Update on the user store) typically returns an IdentityResult. I don't think anything else does. None of the read operations do, which is why I'm resistant to the idea of changing things like Verify/CheckXyz to be IdentityResults

[HaoK]

Merged a8c872a