Link to an external profile when user accounts are managed by a single OIDC provider

[marius-mather]

When user accounts are managed through a single OIDC provider, we want to disable editing of username/email address/password within Galaxy and have them managed at the OIDC provider. This PR disables the username/email/password change UI within Galaxy and instead shows a read-only profile page with a link to the external OIDC profile.

Builds on #20287.

Changes:

• Add a profile_url option to OIDC backend config
• Add a new user preferences widget for showing/linking to the OIDC profile
• Disable username, email and password change based on config

Screenshots:

User preferences page with new profile widget added and "change password" removed (the existing "Manage Information" widget needs to be maintained for managing Galaxy-specific information like addresses and links to other external accounts)

New OIDC profile widget:

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. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

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

[bernt-matthias]

I remember that there was a config variable where the UI for changing this information was just disabled. I authenticate against LDAP and also don't want my users to change this.

Just can't find the config at the moment. Edit:

galaxy/lib/galaxy/config/sample/galaxy.yml.sample

Line 1285 in 426fcd1

#enable_account_interface: true

[marius-mather]

In our case, we want to make sure username and email can't be edited in Galaxy, since these will come from the OIDC provider, but we still want to allow for Galaxy-specific information like addresses and other integrations (e.g. Zenodo). enable_account_interface: false disables these as well (or at least the addresses), so we need to do something a bit more complex than just having everything hinge on enable_account_interface

[nuwang]

@marius-mather At the backend working group meeting, the general consensus was that we should just repurpose enable_account_interface for this. The original behaviour of hiding everything, including user properties, is undesirable, so doing what this PR does with the existing enable_account_interface switch makes the most sense.