feat(TaskProcessingApi): Add endpoint for getting the next task

[provokateurin]

Summary

The ExApps need a way to get the next task.
@marcelklehr I think there is a bug as the tasks are not marked as running when the getNextScheduledTask method of the service is called (or maybe it was also intentional and the endpoint should do it manually).

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[marcelklehr]

Ah, I missed this, yes.

@marcelklehr I think there is a bug as the tasks are not marked as running when the getNextScheduledTask method of the service is called (or maybe it was also intentional and the endpoint should do it manually).

Yeah, let's do this manually directly in the endpoint

[bigcat88]

We need endpoint for getting nextTask by specifying multiple task_types.
One provider can process multiple task types and we do not want to spam NC with one nextTask request for each task_type.

Or just to change string $taskTypeId to array of strings.

[julien-nc]

• I agree with @marcelklehr that it makes more sense to change the task status to "running" in the controller method.
  The Manager::getNextScheduledTask method might be used in some context where we don't want to change to task status.

• Also, how about having a setTaskRunning parameter (with true as default value) in TaskProcessingApiController::getNextScheduledTask ? Just in case one wants to get the next scheduled task without actually processing it.

• About requesting multiple task types in getNextScheduledTask, much needed indeed. @marcelklehr Would you go with another endpoint or change the current one?

[provokateurin]

I don't see a reason why you would ever need to know the next task without also running it at the same time, but I can change it if you really want 🤷‍♀️

[marcelklehr]

I don't see a reason why you would ever need to know the next task without also running it at the same time

The synchronous background job will re-schedule itself based on the fact whether there is another job waiting to be executed.

[marcelklehr]

Would you go with another endpoint or change the current one?

We can add this to the current endpoint.

[provokateurin]

The only remaining part that needs to be implemented. Waiting on an answer from @marcelklehr

[nickvergessen]

this method is callable for any user and it will freely give out any scheduled tasks of other users.

[nickvergessen]

Could also not introduce the annotation (and then simply directly only check for the attribute)