feat(TaskProcessing): add endpoints for ExApp access without userId

[kyteinsky]

Summary

The OCS task processing endpoints require a user to be present even if the requests are coming from ExApps using AppAPI's authentication. This makes it a requirement to choose a user on the instance for scheduling and querying tasks from an ExApp, and choosing that user can be difficult in some cases or the user may not be present so this provides a way for ExApps to access the API without any user involved (userId === null).
Since the API was designed to work without the requirement of any user (for the most part, see passing files in schedule endpoint), this works nicely and also does not allow anonymous user access.

Endpoints added:

• schdule task
• get task
• cancel task
• delete task
• get task types

Should listTasksByApp and listTasks be added? They're not required as of now.

Python code that can be used for testing, needs the ExApp env vars though

import os

os.environ["NPA_NC_CERT"] = "false"

from nc_py_api import NextcloudApp

nc = NextcloudApp()
# nc.set_user("admin")
try:
	# schedule

	# r = nc.ocs(
	# 	"POST",
	# 	"/ocs/v2.php/taskprocessing/tasks_consumer/schedule",
	# 	json={
	# 		"type": "core:text2text:translate",
	# 		"appId": os.getenv("APP_ID", "live_transcription"),
	# 		"customId": f"lt_startup_test_{os.urandom(4).hex()}",
	# 		"input": {
	# 			"input": "Hola, world!",
	# 			"origin_language": "en",
	# 			"target_language": "hi",
	# 		},
	# 	},
	# )

	# get

	# r = nc.ocs(
	# 	"GET",
	# 	"/ocs/v2.php/taskprocessing/tasks_consumer/task/238",
	# )

	# cancel

	# r = nc.ocs(
	# 	"POST",
	# 	"/ocs/v2.php/taskprocessing/tasks_consumer/tasks/238/cancel",
	# )

	# delete

	# r = nc.ocs(
	# 	"DELETE",
	# 	"/ocs/v2.php/taskprocessing/tasks_consumer/task/238",
	# )

	# list task types

	r = nc.ocs(
		"GET",
		"/ocs/v2.php/taskprocessing/tasks_consumer/tasktypes",
	)

	print("taskprocessing response:", r, flush=True)
except Exception as e:
	print("Failed to connect to Nextcloud", e)

TODO

• ...

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)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[julien-nc]

Looks good