Shib logins fail when authentication provider info changes

TL;DR: We rely on the Shib-Identity-Provider: (for ex., https://fed.huit.harvard.edu/idp/shibboleth) and eppn: (xyz@harvard.edu), as supplied by the provider, to identify shib accounts. If an institution decides to change either of the above, shib logins fail in a way that's confusing to the user.

Case in point: HMDC RT #327154.

The symptoms: from the user's point of view, nothing changes in the authentication process on the side of their institution. The internal fields like the eppn and identify-provider are never shown to the user. But when they are redirected back to Dataverse, their account is not recognized - because there is no entry in AuthenticatedUserLookup for the auth. fields presented - so they are shown a new account form. But once they confirm, it fails with a generic error (no reason spelled out) with the exception in the server.log org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "authenticateduser_email_key". I.e. it fails because the user with this email address already has a shib. account (and Dataverse fails to check for that before attempting to create a new account).

The admin-level fix for this is to enable FINE logging on ShibUtil (edu.harvard.iq.dataverse.authorization.providers.shib.ShibUtil.level=FINE); when the user attempts to log in again, this will produce a log entry like

shib values: [Shib-Identity-Provider: xxx, eppn: yyy@zzz.edu, givenName: ..., mail: nnn@mmm.edu, affiliation: ...]
then compare it with the current entry in the lookup table for the user:

SELECT l.id, l.persistentuserid FROM authenticateduserlookup l, authenticateduser u WHERE l.authenticateduser_id and u.email='aaa@bbb.edu'

If it is indeed different from the product of Shib-Identity-Provider + | + eppn from step 1.: If it appears that the user is being authenticated by the same institution (mmm.edu in our example) and they have simply moved their shib to another server, simply update the authenticateduserlookup entry to reflect the changes. If this user is being authenticated by a shib. provider from a different institution with the same email, rather than updating the entry as above, it may be more prudent to convert their account to local, then let them try to log in w/ the new shib provider again, and have the account converted back to shib, but properly reflecting their current affiliation. (These decisions will need to be made on a case-by-case basis; pain in the neck, yes).

The situation appears to be somewhat common, so we need to address it. I'll discuss various ways of addressing it in a separate comment.

Start with the ShibUtil entry point and the AuthenticatedUserLookup records described in the issue, using the FINE log output and PostgreSQL query to trace changed provider values. Review the proposed approaches in the separate comment and define the expected behavior for an existing email before implementing and testing the agreed account-handling flow.