Lack or foreign key use in databases could lead to orphan data

Of all 6 SQL databases:

[`sandbox_metadata`](https://github.com/DIRACGrid/diracx/blob/4ee1b0d81d87433377bbdf0848b34075f437557f/diracx-db/src/diracx/db/sql/sandbox_metadata/schema.py), [`pilot_agents`](https://github.com/DIRACGrid/diracx/blob/4ee1b0d81d87433377bbdf0848b34075f437557f/diracx-db/src/diracx/db/sql/pilot_agents/schema.py) aren't using foreign keys at all. This could lead to orphan data in the database for two reasons:

1. if a pilot is deleted in the `PilotAgents` table, all pilot related data like in `JobToPilotMapping` will not be deleted
2. we could have an unknown `pilot_id` in `PilotOutput` because we inserted a non-existent one (so we are obliged to verify that the new `pilot_id` exists in the database, manually, instead of letting the db verify for us and doing its magic) or because it does not exist anymore (see 1.)

I don't know if this is a choice, or a mistake. If it is a choice, [`task_queue`](https://github.com/DIRACGrid/diracx/blob/4ee1b0d81d87433377bbdf0848b34075f437557f/diracx-db/src/diracx/db/sql/task_queue/schema.py) and [`job`](https://github.com/DIRACGrid/diracx/blob/4ee1b0d81d87433377bbdf0848b34075f437557f/diracx-db/src/diracx/db/sql/job/schema.py) do use foreign keys. And furthermore, even if we check manually, I think it is better to have constraints inside the DB itself, rather than constraints done before.

In the meanwhile, [`job_logging`](https://github.com/DIRACGrid/diracx/blob/4ee1b0d81d87433377bbdf0848b34075f437557f/diracx-db/src/diracx/db/sql/job_logging/schema.py) and [`auth`](https://github.com/DIRACGrid/diracx/blob/4ee1b0d81d87433377bbdf0848b34075f437557f/diracx-db/src/diracx/db/sql/auth/schema.py) can't use it, because the `client_id` is remotely defined in `IAM` if I recall.