Introduce TortoiseContext, remove global state

[abondar]

Since start of Tortoise - it's state, with connections and apps, was stored globally, as class vars on "Tortoise".

This brought number of problems, including #1110 , because in tests we were forced to use hacks with global variables to initiate tests, while also limiting users in how they can initialise tortoise

This PR introduces new TortoiseContext, which encapsulates state of tortoise, allowing you to have several of those simultaneously

Also removed old test infrastructure, replacing it with pytest style one. I hope it should ease adding of new tests as now they are less polluting each other

This PR also introduces a lot of breaking changes, so it will be released as part of 1.0

AI Summary:

This pull request introduces major changes as part of the context-first architecture migration for Tortoise ORM, including breaking changes to test infrastructure, connection handling, and documentation. The update replaces legacy test helpers and fixtures with modern, context-aware pytest fixtures, revises connection access patterns, and updates documentation to reflect the new API and migration guidance.

Breaking changes and migration to context-first architecture:

• All ORM state now lives in TortoiseContext instances, and legacy test classes/helpers (test.TestCase, initializer(), etc.) have been removed. Tortoise.init() now returns a TortoiseContext instead of None. Multiple asyncio.run() calls in sequence now require explicit context management.
• The connections singleton is deprecated; new functions get_connection() and get_connections() provide connection access from the current context. [1] [2]

Testing infrastructure overhaul:

• Legacy test initialization/finalization is replaced by new pytest fixtures (db, db_simple, db_isolated, db_truncate) using tortoise_test_context for robust, context-based test isolation. A fixture factory (make_db_fixture) is provided for custom test modules.
• The test configuration now uses function-scoped fixtures for true isolation and improved performance, with clear documentation for each fixture's use case.

Documentation and migration guidance:

• The connections.rst documentation is rewritten to describe new connection access patterns, context usage, and migration from the deprecated singleton. It now includes practical examples, API reference, and a migration guide table.
• The changelog is updated to warn about breaking changes and provide a detailed migration summary.

Minor improvements:

• Minor formatting and comment changes in documentation and configuration files for clarity.

These changes modernize Tortoise ORM's architecture, improve test reliability and speed, and provide clear migration paths for users upgrading from earlier versions.

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing tech/refactor-context (14415f6) with develop (a1e42df)}

[waketzheng]

Django shell support ipython(which is much more popular than ptpython) as optional deps and will use the built-in Python REPL if ipython not installed.
Is it possible for us to support both REPL/ipython/ptpython?

[abondar]

Problem with default REPL is that it doesn't natively support "await ..."

ipython doesn't have such problem

Only advantage ptpython has that it is smaller dependency than ipython

Probably we could remove ptpython from dependencies and optionally allow ipython and ptpython, depending on what's available

Not sure if it worth it to implement fallback to default REPL

[waketzheng]

1. No need to fallback REPL
2. Optional ipython/ptpython is OK

[abondar]

I'll update it in separate PR