Injecting Context._scope: trio.Nursery errors, probably a ContextCancelled to start

[goodboy]

Writing up some much more detailed tests for remote actor
cancellation as part of #357 has me thinking again about how it'd
be nice to be able to inject our own subtype of .trio.Cancelled
into each internal nursery / scope (on each side of an
inter-actor-task context).

That is @tractor.context and Context.open_context() tasks raise
a ContextCancelled on their next checkpoint when our runtime
desires to indicate a cancellation condition that was triggered by
either Actor.cancel_actor() or Context.cancel() (and/or error
bubbling over IPC?) from one side to the other. This would in
theory make cross process task supervision easier to implement as
well as make it possible to allow the @context side task able to
handle remote cancellation requests (more) granular-ly and possibly
specially?

A further handy use case would be overriding the
CancelScope.__exit__() to allow hiding its stack frame in the
pdb repl; something that's handy if you want to shield a pause
point like:

trio.CancelScope(shield=True):
  await tractor.pause()

and hide the exit frame on REPL initial entry.
(at least this seemed to still be a problem last time i tried to
implement such a thing doing .pause(shield=True))

---

Gitter community suggestions

(Mostly from @oremanj yet again 😂)

• possibly adding a Task.interrupt_with_exception(ContextCancelled) to make a public
  API equivalent of Task._attempt_abort()?

  • applying this approach to a whole cancel scope - this is
    probably not the right abstraction (level)

  • there have been periodic discussions about how to indicate the
    'type' of a cancellation, and I think that would be a better
    fit for your use case. then all the other tasks in the nursery
    will see a normal Cancelled as the exception passes through
    the nursery and causes them to be cancelled. if you want this
    to behave like a normal Trio cancellation then it needs to
    hook into the cancellation mechanism, not the abort mechanism,
    IMO. (this is what we use to deliver KI). yeah, abort can only
    be used to wake up a task that is currently blocked.

• at the very least it'd be handy to be able to mutate/augment the
  Cancelled type for such a thing instead of having to touch the
  entire cancellation system?

---

ToDo:

• write up some basic @tractor.context use cases and see if
  they even really need or make sense having a special
  ContextCancelled raised.
  • for me making class contextCancelled(Cancelled): prolly makes
    the most sense since you can keep all normal exception
    semantics in place but allow code to specially handle the case
    where the cancellation is due to our runtime's cancellation API
    versus something in the client-app code which is *built on
    tractor.