feat(diracx-api): add set_job_status

[Loxeris]

Adds the set_job_status function to set the status, minor status and application status of a job.

Needed for issue DIRACGrid/dirac-cwl#83

[aldbr]

Mostly based on the comments I gave in your other PR in dirac-cwl.

[aldbr]

type is not necessary as you already specify the the type hint within the signature of the function.

[aldbr]

I think job_id is expected to be an int

Suggested change

	job_id: str,
	job_id: int,

[aldbr]

I guess it should be singular here.

Suggested change

	logger.debug("Job statuses set successfully")
	logger.debug("Job status set successfully")

[chaen]

why not just calling the client directly ? There does not seem to be any added logic here ?

[chaen]

@aldbr maybe we should be more explicit in docs/devs/explanations/components/api.md ?

[aldbr]

why not just calling the client directly ? There does not seem to be any added logic here ?

There is actually a very small piece of logic to create and add the timestamp to the request here https://github.com/DIRACGrid/diracx/pull/777/changes#diff-2d32214b7bab7d5a88d21308ad744235df705a7ff238ac879292c6b2a4a364c3R166-R167

In DIRAC, we have:

• a client that can set a single job status in one call (we don't have this in diracx, which is fine but then to reproduce that we need a small function to create the timestamp as done here). It doesn't seem to be called though.
• a JobReport object that adds up different status update before sending them in one call. This is used by the JobAgent and the JobWrapper.

Here I see 2 options for the new job wrapper:

• this diracx-api function to report the status of a given job each time there is an update. It's simple but can create a lot more calls to the services than the JobReport approach though.
• we recreate a JobReport object, that should likely be located on the client side since the JobWrapper does not have a direct access to the DBs and only relies on client dependencies.

Do you have any opinion?

[aldbr]

Note: I am closing this PR, we are going to work on the JobReport design and implementation within dirac-cwl as it's the only place it's going to be used for now.