Allow OIDC to update EMAIL and username (if mapped)

[uwwint]

(Please replace this header with a description of your pull request. Please include BOTH what you did and why you made the changes. The "why" may simply be citing a relevant Galaxy issue.)
(If fixing a bug, please add any relevant error or traceback)
(For UI components, it is recommended to include screenshots or screencasts)

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. create an OIDC only galaxy
  2. register a user
  3. update the users email / username
  4. login into galaxy with that user:
     The username and email are updated.

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[uwwint]

@nuwang Can you help with this one?

[nuwang]

From what I can see, this is always syncing when logging in through an OIDC client? However, since Galaxy allows multiple accounts to be connected, I'm not sure that behaviour is desirable, since users may have one primary email they prefer but have secondary accounts connected.

IMO, I think we should simplify this to use the same conditions as here: #21356
That is, update account only if enable_account_interface: false and only one login provider is configured. That way, we also don't need toast messages and can simplify that bit too.

[uwwint]

Agree @nuwang. Do you want me to rebase on #21356 or wait for the merge?

[nuwang]

The enable_account_interface flag is alrrady presenr so i dont think we need #21356 for this.

[uwwint]

@nuwang Done

[nuwang]

Some comments/suggestions:

1. We can't auto-update the username/email since Galaxy could have multiple account associations, and that raises a question of, which the authoritative ones should be. Instead, I think we could just piggy back on the fixed_delegated_auth config setting - and auto-update the username/email if fixed_delegated_auth is on.  (we already use fixed_delegated_auth to auto-associate emails with no confirmation - and it essentially implies a trust relationship with the OIDC provider)
2. That will also allow us to get rid of the toast message - which adds complexity
3. We should also have an integration test - modelled after the tests here: https://github.com/nuwang/galaxy/blob/26f86934cb0ae0e003aaf871c2ae0ad4e266b0e4/test/integration/oidc/test_auth_oidc.py#L516