Logging into a placeholder person OOPSes if email address already on another person

[William Grant]

Logging into Launchpad for the first time with a new SSO account can crash like OOPS-2652a3a7880bdf5d99969a6bb2df088e if the SSO account has a username set and the SSO preferred email address is already associated with another Launchpad person (eg. an account automatically created by a package upload, or an account that has been deactivated and its corresponding SSO account deleted).

 1) An LP person A is created with the user's email address.
 2) User creates SSO account with that email address
 3) User sets their SSO username, which creates an LP person B with AccountStatus.PLACEHOLDER, and an OpenID identifier but no email address.
 4) User tries to log into LP. getOrCreateByOpenIDIdentifier finds account B, and attempts to activate it with the SSO preferred email address. setPreferredEmail crashes with an AssertionError as the address is associated with A rather than B.

If A is an unactivated autocreated person, an admin can use https://launchpad.net/people/+adminpeoplemerge to merge A into B, allowing the user to log into B and preserving the chosen username. The OOPS verifies that the email address and OpenID identifier are associated in SSO, providing sufficient proof of identity.

If A isn't unactivated and autocreated, more discretion is required.

[William Grant (wgrant)]

To resolve the common case of an autocreated Unactivated A, we could have getOrCreateOpenIDIdentifier rename B account away, rename A into its place, transfer the OpenID identifier across, request a B -> A merge, then activate and log into A.

Other cases are probably rare enough that they can be handled manually; we should reject the login like we do in the team email address case. If A is active then the user can work around it by using their other SSO account, and a manual B -> A merge will unbreak things.

If A is deactivated, we probably don't want to reactivate it; we might want to have a way for an admin to erase the email addresses and OpenID identifiers from a deactivated account to give a user a fresh start, or just use the classic merge to lp-void approach.

[Colin Watson (cjwatson)]

I'm also a bit suspicious of some cases I've seen. It seems to be possible to have a Launchpad account that is still active and has never been deleted, but for the SSO account to have been deleted such that when the user tries to log in again they end up creating a new SSO account with a different OpenID identifier. I don't think SSO should allow deletion in this case.