Allow clients to cancel requests

Dieses Issue hat noch niemand übernommen.

Currently, there is no way for clients to cancel their own requests. This may be desired, for example, if a client sends a `mediation: conditional` request, and then follows up with an `optional` or `required` mediation request based on user interaction.

# Considerations

Clients should not be allowed to cancel other clients' requests, so when a request is created, there should be some context saved inside of the request to separate clients.

# Potential solutions

There are a few of ways to resolve this:

## Allow conditionally mediated requests to be override

Right now, we force a single in-flight request at a time. But perhaps non-conditional requests can be allowed to override other requests. This doesn't require any changes to the API for the example provided above. But this doesn't meet every need, for example, if a client is shutting down and wants to inform us that the request is no longer necessary.

## Session API, context provided by server

-> client sends a request to start a session
<- (server responds with session context)
-- server waits for client to request credential, or times out the session to avoid DoS
-> client sends a synchronous request to complete session on channel A, creates a separate cancellation channel B

and then either:
-> client cancels request from channel B, passing session context from first request
or
<- server responds to request on channel A

This turns this into an "session-based" API, but still allows for a mostly synchronous flow for simple clients that don't care about cancelling their own requests.

If we go this route, a couple of details:
- The server should buffer the response until the client subscribes or some timeout occurs.
- The diagram above is simplified, but cancellation can also occur before client subscribes.

## Context provided by client
Another way to implement this is to let the client pass context:
-> client creates request, with client-provided request ID, waits for response on channel A
-- (server stores client request context, and binds it to the connection context (PID, client bus name, etc., begins processing request)

and then either:
<- server responds to request on channel A
or
-> client sends a cancel request on channel B message with original context ID.
<- Server compares current request context to original request context sends a "request cancelled" response on channel A if accepted, or ignores it.

The only thing that I'm not sure about is whether we can trust the client + connection binding to be sufficient for security, rather than handing out request context generated by the server.

Es werden keine Dateien, Tests oder Einstiegspunkte genannt. Beginne damit zu klären, welches Abbruchmodell und welche Bindung der Client-Authentifizierung das Projekt übernehmen wird; abgeschlossen ist die Aufgabe, wenn ein abgestimmtes Design vorliegt, das verhindert, dass Clients die Anfragen anderer Clients abbrechen, und die Abbruchsemantik vor und nach der Subscription definiert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.