#8 Feat: Large transaction handling

[ckritzinger]

There is an edge case where the transaction is too large (has too many ops) to process in a single API call.

Some discussion has been had around potential solutions to this problem, I propose the following:

• The API supports a second operation that posts operations as part of a transaction, specifying a unique ID for the transaction. The server must save these operations in a staging area without processing
• The API supports an (idempotent) commit action that commits a transaction by ID. The server must run all operations in a batch, and save the results.
• A large transaction may take longer than the API call lifetime to process, so committing a transaction will have to result in a background job processing the transaction and saving the results.
• The server should therefore support querying a transaction after commit. This should return transaction status and results
• We will need some sort of TTL/GC to make provision for crashed clients, so that we don't bloat the staging area

This PR proposes an extension to the OpenAPI description to support this behaviour.

NB: I have not implemented any of the behaviour (client or server), the intent is to obtain consensus on the API semantics before going to that level of detail.

Here's what the sequence looks like: