add display_name field to users and use user_id as unique identifier

[elfkuzco]

Rationale

This PR refactors the API/UI to use both the username and id to perform actions on user views. Since Ory integration, users can have names which are similar to existing users (registered locally) and this would result in a unique constraint violation. To mitigate this, a new column display_name is added to the DB and API responses. This field is not unique and serves as a place to store the names coming from Ory and the locally registered users. For local users, the display name is generally the same as the username.

Changes

• add display_name field to dB and API responses
• allow path parameters to take in either user_id or username (since both are unique)
• refactor UI calls to make requests with user_id instead of username
• refactor logic that prevents unprivileged users from modifying other users into a reusable dependency

This closes #1689

[elfkuzco]

Pending elaboration on #1689 (comment), this seems to align with much of #1689

[codecov]

Codecov Report

❌ Patch coverage is 85.33333% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.55%. Comparing base (5278c9a) to head (f1a783d).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...kend/src/zimfarm_backend/api/routes/users/logic.py	69.56%	3 Missing and 4 partials ⚠️
...end/src/zimfarm_backend/api/routes/dependencies.py	78.57%	2 Missing and 1 partial ⚠️
backend/src/zimfarm_backend/utils/scheduling.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1722      +/-   ##
==========================================
+ Coverage   83.35%   83.55%   +0.19%     
==========================================
  Files          97       97              
  Lines        4837     4853      +16     
  Branches      500      496       -4     
==========================================
+ Hits         4032     4055      +23     
+ Misses        671      667       -4     
+ Partials      134      131       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[benoit74]

LGTM, one minor fix and you can merge.

I'm not satisfied anymore at all by the user screens, but let's move this topic to a distinct issue, this PR already achieves what we need to be able to handle (way beyond what was originally foreseen in the issue description), and UI rearrangement is more a detail.

Before merging, can you double check we will not break any "running" thing due to API change (besides the frontend which will have to be updated as soon as API is updated of course, I'm more thinking about workers and tasks). I don't think so, but I prefer to ask ^^

[elfkuzco]

Before merging, can you double check we will not break any "running" thing due to API change (besides the frontend which will have to be updated as soon as API is updated of course, I'm more thinking about workers and tasks). I don't think so, but I prefer to ask ^

Yup. Nothing should break. There's no logic to change token decoding or key authentication with SSH (so long as workers have username since that's used in generating the auth message). Tested locally with a new task and everything works fine.