Splitted the job endpoints to separate Pilots and Users

[Robin-Van-de-Merghel]

Reopened*

Implementation for #444

Some interrogations about my understanding of this policy:

• We do need to check for a job_id associated with a pilot? (already implemented)
• With job_ids, I assumed that a pilot can manage only one job at a time, do we?

[chrisburr]

With job_ids, I assumed that a pilot can manage only one job at a time, do we?

A pilot can potentially be running many jobs at the same time (via PoolCE in legacy DIRAC).

[Robin-Van-de-Merghel]

A pilot can potentially be running many jobs at the same time (via PoolCE in legacy DIRAC).

I just added it. I guess I have to do tests on the endpoints for the policy, I'll do it later today.

[Robin-Van-de-Merghel]

Router won't pass the tests: we need to have in the factory (or somewhere else) a pilot token generator (but not a "pilot_client" as normal_user_client, because we can't stack multiple contexts).

[chaen]

Just to sum up the path we are taking: legacy DIRAC code will still rely on the legacy exchange and on a robot user for its pilot duty, so it will keep using the "traditional" endpoint (like /job/heartbeat.
However, new pilot code, using solely diracx will not have a robot user, will rely on pilot credentials and will use the new endpoint. It should never be possible to get a pilot credential from the legacy exchange
The code duplication is absolutely none as the business logic is factorized.