When an account is converted from builtin to Shibboleth, the position is preserved and becomes uneditable

Based on what I'm reading at https://help.hmdc.harvard.edu/Ticket/Display.html?id=420257 I'm guessing the following happened:

• The user had a builtin account with a position filled in, such as "Associate Professor".
• The user converted their account from builtin to Shibboleth. The "Associate Professor" position was retained in the user account but (like all fields) became uneditable because it's now a Shibboleth account.
  • This uneditability is a (somewhat controversial) feature. It is described like this in the User Guide: "Please note that you cannot edit your account information within the Dataverse installation if you use the Institutional Log In option. Instead, you should contact your institution to change your name, email, etc. Once the change is made by your institution, it will be reflected in the Dataverse installation the next time you log in. Users of the Institutional Log In option are not required to verify their email address because the institution providing the email address is trusted." -- https://guides.dataverse.org/en/6.11/user/account.html#edit-account
• The user got a promotion and is now a full professor.
• Because no fields are editable for Shibboleth users, the position cannot be updated.

Here are some screenshots showing the steps above.

User creates builtin account

User converts their account to Shibboleth

User cannot edit any account fields, including position

I know that authentication is very much in flux with the new React-based frontend coming along but if we were to fix this bug I would suggest that we delete any value from the "position" field when the account is converted from builtin to Shibboleth. My reasoning is that for Shibboleth accounts, the position field is never updated. There's a comment in the code to think about how we would pull the position from the Shibboleth assertion, the way we do for name and email. We never figured out a good way to do this so I think that for Shibboleth accounts, the position field should simply be blank, since it can't be edited and is never updated. (We could try to figure out how many accounts in Harvard Dataverse are in this state of being Shibboleth accounts and having the "position" field that can't be updated.)

Since Shibboleth accounts never have their position updated, the workaround involves a manual database update. We could ask the user what the new position should be and manually update it. This doesn't scale particularly well. Instead, as with the proposed fix above, I'd suggest blanking it out, deleting the value from the "position" field for the affected Shibboleth user. The column is called "position" in the authenticateduser table.

Start by reading the builtin-to-Shibboleth conversion flow and the comment around Shib.java line 276, then inspect the position column in the authenticateduser table. Define the expected behavior for converted accounts and add coverage for the conversion path; done when the position no longer remains populated for affected Shibboleth users.