Consider relaxing the await-always-checkpoints rule to await-always-checkpoints-on-non-error

[njsmith]

Currently, all the async functions in trio proper attempt to always issue a checkpoint on every call. The idea is that you want to be able to tell from reading your code where the checkpoints are, so this makes it more predictable – it's a static guarantee, so you don't have to reason carefully about unclear runtime conditions, and it's easy to explain to users.

However, I'm wondering if we might want to relax this slightly: maybe the rule should be, trio's async functions always checkpoint, unless they raise an exception (in which case there's no guarantee either way).

The reasoning here is that guaranteeing the checkpoint invariant for error paths turns out to be very tiresome and error-prone, both to implement and to test. Also, in some sense it's actually impossible to get this perfect – e.g. if you accidentally do await trio.sleep(1,5) then Python will raise TypeError: sleep() takes 1 positional argument ... before even invoking the function, so this call doesn't checkpoint.

Furthermore, we can guess that usually users aren't going to be caring about checkpoints for operations that raise exceptions... for example, it'd be unusual to have a loop where the only await was on an operation that always raised an exception that you caught and then looped around on. And the proposed rule is easy to explain, though not quite as easy as the original rule.

Another nice thing is the rule is still sufficiently deterministic that we could check it automatically, as suggested in #152.

[smurfix]

+1

[njsmith]

This has been annoying me again recently, and I'm not thinking of serious downsides. Let's do it.