Do not convert calculated lockedOutUntil time to UTC

[Migaroez]

Prerequisites

• I have added steps to test this contribution in the description below

Fixes #16988

Description

Back when Identity was upgraded to identity core, an oversight was made in the code conversion that ended up in a UTC time being stored inside a dateTimeOffset which results in Identity LockoutEnd value being set to values that do not correspond to the intend with the following timezone ranges

• For timezones in the +X range this results in lockouts taking longer than intended.
• For timezones in the -X range this results in a lockout never happening if the offset was bigger than the configured DefaultLockoutTimeInMinutes.

Testing

• Set the Umbraco::CMS::Security::MemberDefaultLockoutTimeInMinutes setting to a managable time (like 1 minute)
• Implement a member login/logout flow, member group, member and protected content
• Lock the member out by trying to login with an incorrect password equal to Umbraco::CMS::Security::MemberPassword::MaxFailedAccessAttemptsBeforeLockout setting
• Check that the behavior in the description no longer happens and the lockout is lifted correctly on the next correct login attempt after the LockoutTimeInMinutes has passed. (and not before)

[AndyButland]

I had a look at this one @Migaroez as can see it's not been reviewed yet. Unfortunately I couldn't get it to work for me.

What I found was that if I run locally - so local time is CET (i.e. UTC + 1) - if I was logged out as a member I couldn't login again after the one minute configured MemberDefaultLockoutTimeInMinutes had passed. It seemed I would have to wait for one hour and one minute.

The reason I believe is that the lockout end, defined on Microsoft's IdentityUser is meant to be in UTC (see comment):

    /// <summary>
    /// Gets or sets the date and time, in UTC, when any user lockout ends.
    /// </summary>
    public virtual DateTimeOffset? LockoutEnd { get; set; }

So that seems like the original code was correct in trying to set this to universal time.

The problem seemed to be that the dates set on IMember that we are mapping from here are server time, but they have a Kind set of Utc. Hence the call to .ToUniveralTime() wasn't doing anything.

I've amended this to explicitly set the kind to local before doing the conversion to UTC, and that seems to work.

My expectation is that this is kind of a plaster on the problem that we are getting these "invalid" dates here (i.e. server time, but with a Kind of Utc), but it does look to resolve the issue for these dates that have to be correctly converted to UTC for the lockout feature to work.

Can you see what you think please? And re-verify the fix?

[Migaroez]

Seems to work perfectly now, thx @AndyButland

[AndyButland]

Great, I'll approve and merge then. Thanks for checking it over again.