There are various web services in core and implemented in plugins which have been turned into async tasks. eg MDL-28505 for course backups.

This is a rainy day idea to allow all webservices to be run async in a generic way following a pattern that many other api's in the wild allow.

The point of this is to cater properly for long running expensive tasks which have all sorts of issues when run synchronously on a web server with connection timeouts and other timeouts. And to also correctly cater for fails and re-tries etc.

This is all possible right now with the webservice manually queuing up its own tasks but requires a lot of 'boiler plate' handling which could easily be done centrally and in a consistent way in core allowing for a much better developer experience.

Broadly it would be something like:

1. Either a new endpoint or an optional extra set of async parameters that all web services accept implicitly
2. This is fully managed by the webservice system and each web service is unaware that it is being called async
3. The caller optionally provides a webhook callback url
4. The system serializes the request and queues it into an adhoc task
5. It immediately returns a response that includes a url which can be used to check the status of the async request
6. The adhoc task runs the webservice function and captures its return values
7. The return value is pushed via the optional webhook callback url provided in step 1
8. At any time calling the status endpoint tells you if the task is still queued, or running, or run and failed, or run and succeeded
9. Maybe: If the webservice succeeded you can also get the return value via the status endpoint. This means we need to persistent the return values and then expire them out which might not be desirable in all cases. It might be better if it step 1 the calling api can pass in a 'mode' which says if the return value is only pushed back via the callback, or if it is available by the status.
10. We also might want to cater for the result being a pluginfile which is retrieved via webservice tokens asynchronously. (eg MDL-73291) so you call the web service, it calculates the result, and then returns a pluginfile url where you can receive the results. This is better for anything which returns a binary file where the web service return data structure serialization is ill suited to the data being returned.

This could adopt any appropriate standards out there eg the openapi

https://learn.openapis.org/examples/v3.0/callback-example.html