Structured concurrency: TaskHandle

[Attila Kelemen]

> The STS API tries to keep things simple. Calling shutdown means you are
> done and not interested in the results/outcome of the subtasks that have
> not finished. They will be interrupted, and the close method will block
> until the stragglers have finished.
>

Calling shutdown could also mean that I would care about the result,
but I lack faith that the task will complete in a reasonable time.
However, the process might be waiting on something that it cannot
cancel (for whatever reason), and at that point - since it will be
computed anyway - I want to see the result. Consider a UI, it would be
rude for the UI, that even though it computed the result I requested,
refuses to show the result to me.

> In your 1-4 cases, all will cancelled. If this were API for a thread
> pool with a task queue then more insight into the state of the system at
> shutdown might be interesting, as might collecting results/outcome after
> shutdown, but I think that is beyond where this API should be at this point.
>

If the goal is to be minimal, then I think the API shouldn't concern
itself with cancellation at all (it is kinda a false promise), and
should do what Rémi proposed: Fail on cancellation with a specific
exception (it is a little bit awkward that we have both
`InterruptedException` and `CancellationException`, but something must
be chosen anyway). Completely skipped tasks should not be passed to
`handleCompleted`.

I know that there is the potential worry that if `shutdown` was
called, then the threads were interrupted, which might have changed
their behaviour even though they returned normally. However - if this
is a worry (and I would say it rarely is) - then it is trivial to
handle by the caller, since the caller knows that it called
`shutdown`.