Add Cam Users API password integration

Part of: #79 (closed)

Description

Adds integration to password setting Cam Users API.

Refactors the setting for the user update topic to be more descriptively named, but avoids breaking change by allowing old infra variables (maintenance ticket to be raised to remove/deprecate old settings).

Removes PoC code.

Note: The tests completely mock out the authentication dance with GCP credentials -> Entra credentials. This is just too difficult to test in a local environment, and will need to be tested in a "real" env - so will be done in https://gitlab.developers.cam.ac.uk/uis/devops/iam/activate-account/infrastructure/-/issues/119

Changes Made

• Updates password endpoint to call cam users API
• Updates the topic-writing code to be shared between AUP accept and password set updates.
• Adds new settings and refactors old AUP accept settings (although old settings can be used for compatibility).
• Removes PoC code.

Review Checklist

Reviewers should check each item in the below checklist. At a reviewers discretion, some items can be skipped (e.g. documentation only MRs do not need to have tests).

If you feel you can't completely verify any of the below items, or if you simply want a second pair of eyes on an MR, the initial reviewer should message the dev team or ping potential additional prospective reviewers in a comment.

• The changes made meet the acceptance criteria in the linked issue, or the rationale for not meeting the acceptance criteria is appropriate and correct.
• The code changes conform to general and our internal style and quality expectations.
  • Code should be idiomatically consistent with the language.
  • Function and variable names are correct.
  • Functions are purposeful, i.e. split down into smaller functions for re-use or to meaningfully improve readability (e.g. avoid single-line functions).
  • Logical complexity is minimised where possible.
  • Complex logic is explained with comments.
• Changes that will affect the operation or usage of the application from an operational or developer are explained in the README, if they deviate from standard DevOps wide approaches, boilerplate, etc.
• The commits are logically self-contained, and conform to conventional commit format.
  • Commits without the feat or fix type (e.g. chore or ci) are used appropriately, e.g. they are for:
    • Documentation-only commits.
    • CI changes that will not affect the built image in any way.
    • Developer environment changes that will not affect the built image in any way.
  • If the change will be a breaking change it is marked as such.
    • Breaking changes should be avoided where possible.
    • Breaking changes include changes that require updates to the infrastructure in order to be deployed successfully (e.g. new required configuration items)
• Correct tests been added to fully exercise new business logic.
  • No tests have been added which only exercise external/3rd party logic (e.g. testing that a 500 response is returned on exceptions and no other exception handling behaviour is present, etc.). Tests should exist to ensure our wiring and plumbing is correct.
  • Tests exercise functionality to the logical boundaries, i.e. do not over-mock.
• The poe up/npm run up command correctly runs and starts the container.
  • Migrations run (if present).
• The added functionality can be demonstrated locally.