Please allow keyword arguments of deterministic scheduling and random-value generation

[joelb123]

Deterministic scheduling is a very desirable characteristic for user code testing where external interactions can be mocked-up. In my view, this is one of the major advantages of trio over asyncio. Deterministic scheduling is controlled by the following two lines in core/_run.py:

_ALLOW_DETERMINISTIC_SCHEDULING: FinalT = False
_r = random.Random()

Right now these are monkey-patched by pytest-trio, but not all user code uses pytest-trio to create test runners (for example, anyio). Downstream users are thus left to monkey-patch the runner factory themselves.

It would be nice if Trio's constructor had these as keyword arguments. I think separate arguments would be best, because I can think of cases where one might wish to control random-value generation without incurring the performance hit of deterministic scheduling.

[Zac-HD]

They're not actually handled by pytest-trio; precisely for this kind of compatibility the Hypothesis-supporting code was moved into Trio itself in #2981.

However, I don't think it's worth adding top-level arguments which puport to make things deterministic until we've addressed the I/O challenges listed in #3089 and then any other problems that we discover in the process.

[jakkdl]

#3089 sounds fairly ambitious, and it even talks about wanting a separate flag to enable anyway, so given the requests for it I think we could at least make it easier to enable mostly-deterministic scheduling instead of having people do sketchy monkeypatching. Whether that's a top-level argument with an explicitly sketchy name like enable_mostly_deterministic_scheduling=True or a private global variable (maybe in trio.testing?) that's semi-publicly documented to be the ""proper"" way of doing it.