Defer KI if trio is doing IO

[A5rocks]

Supersedes #1537.

As with that, fixes #151, first step of #733.

Additionally, fixes part of #3007 (not intentionally, just because it has to be done in order to still raise a KI. I should add a test.).

[A5rocks]

codecov failure doesn't make any sense and seems to be a recent thing. I'm inclined to believe it's some change in how they normalize file names but I don't think it's worth chasing down for now.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.75077%. Comparing base (ea03051) to head (f83ebbb).

Additional details and impacted files

@@                 Coverage Diff                  @@
##                 main       #3233         +/-   ##
====================================================
- Coverage   100.00000%   99.75077%   -0.24923%     
====================================================
  Files             127         127                 
  Lines           19266       19259          -7     
  Branches         1301        1300          -1     
====================================================
- Hits            19266       19211         -55     
- Misses              0          45         +45     
- Partials            0           3          +3     

Files with missing lines	Coverage Δ
src/trio/_core/_run.py	99.61353% <100.00000%> (-0.38648%)	⬇️
src/trio/_core/_tests/test_cancelled.py	100.00000% <100.00000%> (ø)
src/trio/_core/_tests/test_guest_mode.py	100.00000% <100.00000%> (ø)
src/trio/_core/_tests/test_ki.py	100.00000% <100.00000%> (ø)
src/trio/_repl.py	100.00000% <100.00000%> (ø)

... and 8 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jakkdl]

Is the change to the abort parameter tightly bound to the other changes in this PR? Can it be pulled out into a separate PR?

This is a daunting PR to review, with one former PR and 4 related issues, and changes in 23 files, and it might be more manageable if it got split up.

It'd also be nice if the PR summarized the state of discussion, I don't know if KI-deferral has been unanimously agreed to be the better way to do it, or if there's up- & downsides.

Sorry for the non-review review <3

[A5rocks]

I can do the change to abort fn as a follow up -- it needs this change because the reason it's a function is because KI can be raised (which this change stops), but this change doesn't depend on it.

This isn't so much a summary but see #733 (comment) (this is ~just about that issue, other issues being closed is just because this is a Good Idea and unlocks easy fixes).

[A5rocks]

Alright, I removed the abort function signature change.

[jakkdl]

seems fine as far as I can tell~

[jakkdl]

what's required for this?

[A5rocks]

Well the issue here is that in the above test, no __context__ tree is kept which is wrong. Maybe.

But now that I think about it more, I think this might be fine? If a task is busy-looping it'll raise a KeyboardInterrupt too. I don't really like the Cancelled tree so maybe we should do the opposite of this and try to eliminate it! I'll update this to have this written down. (I'd rather know whether this tree of cancellation is actually a burden but I suspect it'll add many lines to tracebacks in event of ctrl+C for not much use)

[A5rocks]

Looking at #3030 makes me unsure whether this will work with that (specifically pressing ctrl+c when some async code is already running seems like it would break with this). I'd rather have that first, so I'll mark this as a draft.

I guess that PR doesn't actually touch the code I'm worried about, but I want to copy over whatever style of test case we figure out anyways.