Should we expand our test suite by running some downstream projects tests in our CI?

Apparently trio v0.11.0 broke trio-websocket, do to a subtle interaction between our deprecation logic and the import statement: https://github.com/HyperionGray/trio-websocket/issues/102

I can't think of any way we could have anticipated this particular issue. I mean, besides "be smarter", but "be smarter" is not a plan. It never occurred to us that supporting the exact statement import trio.ssl was part of our API, or if it was, that it was a part that could break.

One possible hedge against issues like this would be to have a CI job that runs the test suites for some downstream projects like trio-websocket, just to better align what we test versus what people use in the real world. No guarantees, but it'd give us a better chance of catching stuff like this in the future.

trio-websocket is an obvious candidate for this. What else? trio-asyncio, pytest-trio? hypercorn/quart-trio? (CC @pgjones) Of course we can pick a list now and then adjust it over time.

Start by reviewing the existing CI setup and the downstream projects named in the issue: trio-websocket, trio-asyncio, pytest-trio, hypercorn, and quart-trio. Determine which projects and test suites should be included, then define a CI job whose successful runs demonstrate compatibility with the selected downstream projects.