Introduce user settings

[tcompa]

Branching from https://github.com/fractal-analytics-platform/fractal-server/issues/1769#issuecomment-2357734952 with a more specific plan.

Database

• [x] Create new table user_settings with a set of nullable string columns:
  • [x] ssh_host, ssh_username, ssh_private_key_path, ssh_tasks_dir, ssh_jobs_dir - ref #1768
  • [x] slurm_user, cache_dir, slurm_accounts - ref #1786
• [x] Setup an one-to-one relationship between user_oauth and user_settings, through a FK columns on the user side. We will later make this required - ref #1781
• [x] Add ORM relationship from user to user settings (user_oauth.settings)
• [x] Setup cascade delete: deleting a user also deletes their settings (note: this action is not exposed in the API)

Two-steps rollout (and update-db-data script)

The two-steps rollout is described in #1786. Running update-db-data for v2.6.0 should lead to a state which is fully usable, and where all relevant information has already been moved to user_settings.

• [x] Create a single settings row per existing user, and establish one-to-one relationship
• [x] Copy user attributes into user_settings (slurm_user, slurm_accounts, cache_dir)
• [x] Copy global variables into user_settings (SSH-related ones)

API

User API

• [x] User registration must also create an empty settings row
• [x] Remove legacy attributes from User Update/Read schemas

Settings API

• [x] Set up SettingsRead response schema, with a SettingReadStrict version which is visible to users
• [x] Add GET /auth/users/{user_id}/settings/ and /auth/current-user/settings/ (paths TBD), which returns the user's settings.
• [x] Add PATCH endpoints for /auth/users/{user_id}/settings/ (path TBD) and for /auth/current-user/settings/, with different request-body schemas. For the moment, the current-user SettingsUpdateStrict schema will be empty, while the superuser-only SettingsUpdate under /users includes all columns.
• [x] A note for the backend: it seems that the /auth/users/{user_id}/settings endpoint accepts empty strings in the SLURM accounts array: slurm_accounts: [""]

Task-collection and job-execution API

• [x] Establish validation schema for the required settings in a given context (e.g. SSH job execution)
• [x] Let's add slurm_accounts: list[str] to the required and validated settings, both for sudo and ssh slurm backends
• [x] Establish validation model for slurm-sudo backend
• [x] Perform validation in SSH task-collection endpoint
• [x] Perform validation in standard task-collection endpoint EDIT: not needed
• [x] Perform validation in V1 job submission endpoint (as for V2)
• [x] Perform validation in V2 job submission endpoint
• [x] Propagate the user settings to v1 job-execution background task
• [x] Propagate the user settings to v2 job-execution background task
• [x] Propagate the user settings to v2 standard task-collection background task
• [x] Propagate the user settings to v2 SSH task-collection background task
• [ ] Replace all user.slurm_user with user.settings.slurm_user

Task-collection and job-execution subpackages

• [x] Use the new settings in the SSH task-collection background tasks
• [x] Use the new settings in the SSH job-execution background tasks
• [x] Use the new settings in the v1 slurm-sudo background tasks
• [x] Use the new settings in the v2 slurm-sudo background tasks

[tcompa]

New UserSettings columns: slurm_user, slurm_accounts, cache_dir

UserSettingsUpdateStrict is the same as current UserUpdateStrict, while UserSettingsUpdate may modify all columns.

For the moment, we do not modify the User API/schemas.