Either optimize yield_briefly or de-optimize yield_briefly_no_cancel

[njsmith]

Right now yield_briefly_no_cancel has a special-case implementation in the run loop, while yield_briefly is implemented like (schematically):

with open_cancel_scope(deadline=-inf):
    await yield_indefinitely(lambda _: Abort.SUCCEEDED)

It was done this way because at the time I wrote them, yield_briefly_no_cancel couldn't be implemented any other way. But in the mean time we gained shielding, so now it could be

with open_cancel_scope(deadline=-inf, shield=True):
    await yield_indefinitely(lambda _: Abort.SUCCEEDED)

This is kinda weird and awkward. I'm not sure which way to standardize, though. yield_briefly_no_cancel is currently much faster than yield_briefly, because setting up and tearing down a cancel scope with a non-trivial deadline has non-trivial costs (at least compared to the other costs for these tiny operations). But the implementation is definitely more complicated. So we should decide whether we want to optimize yield_briefly, or de-optimize yield_briefly_no_cancel.

[belm0]

+100 for the faster implementation, and allowing sleep(0) and checkpoint() to benefit.

Trio takes on this complexity, and countless CPU cycles in the universe are spared.

[belm0]

note from gitter, as the cited function names have changed

right now cancel_shielded_checkpoint is implemented using a special-case in the task suspend/resume logic: see here and here

but checkpoint is implemented in a naive way, using a regular cancel scope that expires immediately

[oremanj]

Fixed by #1613.