Add "cancellation" support - AbortSignal

Almost all the methods are async. However, there is no way to cancel these async tasks.

What if we extend InteractionOptions with an AbortSignal ?

export interface InteractionOptions {
  signal?: AbortSignal,
  formIndex?: number;
  uriVariables?: object;
  data?: any;
}

For example, we could imagine:

// client
function run(thing: ConsomedThing) {
  const controller = new AbortController();
  
    // after 1000ms we abort the promise
    const timer = setTimeout(() => {
      controller.abort('timeout');
    }, 1000);

  // read the value
  return thing.readProperty('state', { signal })
    .then((output: InteractionOutput): Promise<DataSchemaValue> => {
      return output.value({ signal });
    })
    .finally(() => {
      clearTimeout(timer);
    });
}

Minimal scenario: the ConsumedThing aborts any async tasks related to this readProperty call (ex: aborts a fetch) and returns a rejected Promise (with an AbortError if we accept DOMErrors).

Extended scenario (optional): same as minimal scenario, but we may send an "abort" request too. In this case we may think about:

// server
function run(thing: ExposedThing) {
  thing.setPropertyReadHandler('state', ({ signal }) => {
    return fetch('https:///another-api.com', { signal });
  });
}

The client send an "abort" request for a specific property (ex: /property-name/abort/), or maybe if the server detects that the connection was terminated before he was able to send the property's value. In this case, the received signal in setPropertyReadHandler is aborted.

Start by locating InteractionOptions and the ConsumedThing asynchronous operations described in the issue. Trace how readProperty and InteractionOutput.value propagate options, then determine the minimal cancellation behavior and how an aborted task should reject. Done means the proposed AbortSignal behavior is defined for the minimal scenario; the optional server-side abort flow remains a separate design question.