Refactor cancellation system to eagerly propagate effective state

This synthesizes the ideas that arose in the discussion on python-trio#910.
Each CancelScope `with` block now creates a CancelStatus object
(not exposed publicly); the CancelStatus objects know their
parent/child relationships in the lexical nesting tree of
CancelScope contexts, and communicate to propagate cancellation
information eagerly. The upshot is that the question "is this
task in a cancelled scope right now?" can now be answered
in O(1) time, eliminating a notable inefficiency in Trio's
run loop. As a nice side benefit, manipulations of the
cancellation tree such as are required by `nursery.start()`
become much easier to reason about.

docs/source/reference-core.rst

@@ -519,23 +519,7 @@ objects.
       most recent ``with`` block. (It is reset to :data:`False` each
       time a new ``with`` block is entered.)
 
-   .. attribute:: cancel_called
-
-      Readonly :class:`bool`. Records whether cancellation has been
-      requested for this scope, either by an explicit call to
-      :meth:`cancel` or by the deadline expiring.
-
-      This attribute being True does *not* necessarily mean that the
-      code within the scope has been, or will be, affected by the
-      cancellation. For example, if :meth:`cancel` was called after
-      the last checkpoint in the ``with`` block, when it's too late to
-      deliver a :exc:`~trio.Cancelled` exception, then this attribute
-      will still be True.
-
-      This attribute is mostly useful for debugging and introspection.
-      If you want to know whether or not a chunk of code was actually
-      cancelled, then :attr:`cancelled_caught` is usually more
-      appropriate.
+   .. autoattribute:: cancel_called
 
 
 Trio also provides several convenience functions for the common

newsfragments/58.misc.rst

@@ -0,0 +1,4 @@
+The plumbing of Trio's cancellation system has been substantially overhauled
+to improve performance and ease future planned improvements. Notably, there is
+no longer any internal concept of a "cancel stack", and checkpoints now take
+constant time regardless of the cancel scope nesting depth.

newsfragments/958.bugfix.rst

@@ -0,0 +1,4 @@
+Inspecting the :attr:`~trio.CancelScope.cancel_called` attribute of a
+not-yet-entered cancel scope whose deadline is in the past now returns
+``True``, like you might expect. (Previously it would return ``False``
+due to an artifact of the mechanism used to track deadline expiries.)