We've built a few ETL processes using Durable Functions that fan-out to thousands of activities. If we find a problem anywhere, we still generally have to wait for all child functions to finish execution, even if we terminate the parent orchestration directly (which is related to #153 but I'm including activities as well here).

It would be really useful and save a lot of time for us to be able to gracefully cancel OR abort child functions based on a parent instance being terminated. I could envisage this working (hypothetically) in a couple of ways:

1. Inject CancellationToken into activity / sub-orchestrator function signatures, so that function code can check for cancellation on this token whenever possible. This also supports opt-in to the feature when required, similar to ILogger injection.
2. Abort execution immediately by throwing a specific exception type on the underlying thread running the child code (OperationCanceledException or similar) - this might require different high-level operations on the client API (eg TerminateAsync with new options to mimic cancel vs abort semantics)

These are common approaches that I've seen before for cancelling / aborting long-running jobs. It would be great to understand if this is something on the roadmap for delivery, as it is something missing that would be trivial to do in standard .NET apps.

Additionally, for fan-out scenarios, if the parent instance is terminated and a child activity has not been executed yet, it should just be removed from queues and not executed at all.

Having the ability to abort functions as quickly as possible becomes particularly valuable when the work being performed could be very damaging to a business (eg, accidentally mailing confidential information to the wrong group of users).