Disallow absolute deadlines for relative cancel scopes

[A5rocks]

This just converts our deprecations into RuntimeErrors. It's been long enough!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00000%. Comparing base (3dd35d7) to head (b99abbd).
⚠️ Report is 11 commits behind head on main.

Additional details and impacted files

@@               Coverage Diff               @@
##                 main        #3403   +/-   ##
===============================================
  Coverage   100.00000%   100.00000%           
===============================================
  Files             128          128           
  Lines           19424        19417    -7     
  Branches         1318         1318           
===============================================
- Hits            19424        19417    -7     

Files with missing lines	Coverage Δ
src/trio/_core/_run.py	100.00000% <100.00000%> (ø)
src/trio/_tests/test_timeouts.py	100.00000% <100.00000%> (ø)

🚀 New features to boost your workflow:

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

[A5rocks]

I've added a change that allows trio.CancelScope to switch from being relative to absolute. I know this wasn't the original design, but thinking through the deprecation note made this seem like a good change. I'd be happy to remove this change, I've kept it in a separate commit so we can revert it easily.

[jakkdl]

I've added a change that allows trio.CancelScope to switch from being relative to absolute. I know this wasn't the original design, but thinking through the deprecation note made this seem like a good change. I'd be happy to remove this change, I've kept it in a separate commit so we can revert it easily.

I think this is slightly footgunny:

with trio.CancelScope(relative_deadline=7) as cs:
  ...
  # nvm we want delay it 10 seconds
  cs.deadline = 10
  # oops now we instantly cancel

the properties are so similarly named, that I think it could be easy to mistakenly type one instead of the other, or overlook/get confused when reading the code. And I don't think it's a necessary API since if you really want to "switch type" you can do so explicitly by doing simple math with trio.current_time().
The biggest reason I can see is if you're passing around a CancelScope that you don't know if it's relative or not, and we want to avoid the hassle of checking CancelScope.is_relative/introduction of bugs by forgetting to check it.

[A5rocks]

I'm not so sure it's that much of a footgun given it's only before we enter the cancel scope, but TBH it's really unnecessary. I guess if people complain, we can think about the right way to do this but I'll just undo those commits.

[jakkdl]

I'm not so sure it's that much of a footgun given it's only before we enter the cancel scope, but TBH it's really unnecessary. I guess if people complain, we can think about the right way to do this but I'll just undo those commits.

okay yeah it's def less bad when you can only do it before entering. Forcing them to recreate the scope when changing type seems fair enough though