Introduce user settings

[tcompa]

Branching from #1769 (comment) with a more specific plan.

Database

• Create new table user_settings with a set of nullable string columns:
  • ssh_host, ssh_username, ssh_private_key_path, ssh_tasks_dir, ssh_jobs_dir - ref Split FRACTAL_SLURM_SSH_WORKING_BASE_DIR into tasks/jobs #1768
  • slurm_user, cache_dir, slurm_accounts - ref Deprecate use of user's slurm_user, cache_dir and slurm_accounts #1786
• 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 Make UserOAuth.user_settings_id required #1781
• Add ORM relationship from user to user settings (user_oauth.settings)
• 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.

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

API

User API

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

Settings API

• Set up SettingsRead response schema, with a SettingReadStrict version which is visible to users
• Add GET /auth/users/{user_id}/settings/ and /auth/current-user/settings/ (paths TBD), which returns the user's settings.
• 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.
• 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

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

• Use the new settings in the SSH task-collection background tasks
• Use the new settings in the SSH job-execution background tasks
• Use the new settings in the v1 slurm-sudo background tasks
• 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.