Improve/redesign /v1/actions API (streaming? background jobs?)

[julianbrost]

The current /v1/actions suffers from a number of limitations:

1. If the action isn't cheap and affects many objects, it may take long (possibly in the order of minutes) until the response is started. This happens because the response code currently reflects the overall status which requires the request to be fully processed. While processing, the client can't really distinguish between the request being processed and a dead connection.
2. The response is wrapped in a single JSON object {"results":[/* result 1 */, /* result 2 */, /* ... */]} which means that clients, that only want to iterate over the individual results once, have to either load the full response into memory or have to resort to more complex JSON parsing methods.
3. Clients need to keep a connection open for long-running API actions.

The first point already came up as part of #10544, but it turned out that can't really be fixed without breaking changes (see #10554 (comment) for the discussion). Thus, this issue shall serve as a place to discuss different possible approaches instead of implementing the first that comes along.

Ideas that came up so far:

1. New API interface, possible both as /v2/actions or opt-in by a header (Accept: application/x-ndjson or Accept: application/jsonl) that uses newline-delimited JSON (i.e. one result object per line without a surrounding object) and is clear from the beginning that the response is streamed, thus the HTTP response code does not convey general success.
2. Introduce a new concept of background jobs to the API. A client could then trigger an action and would immediately receive a response indicating that the task was started. The response would also include a job ID that can be used to query the status of the background job.

So far, the description focused primarily on the current /v1/actions API, but other API endpoints could also benefit from the changes, for example:

• /v1/objects for requests that can affect many objects, in particular POST (modify existing objects) and DELETE (as you might have guessed, deletes objects). GET was already solved by Refactor HTTP connection handling and some handlers to stream responses #10516 for the server side (Icinga 2) but for clients, something like newline-delimited JSON would allow easier parsing and processing without having to load the whole response into memory.PUT only creates single objects so it isn't affected.
• /v1/config deployments already are background jobs, but the means for querying job status are a bit rudimentary. If we chose to implement something for background jobs, bringing the same interface to this API might benefit it as well.