Fixed #31395 -- Made setUpTestData enforce in-memory data isolation.

Since it's introduction in Django 1.8 setUpTestData has been suffering
from a documented but confusing caveat due to its sharing of attributes
assigned during its execution with all test instances.

By keeping track of class attributes assigned during the setUpTestData
phase its possible to ensure only deep copies are provided to test
instances on attribute retreival and prevent manual setUp gymnastic to
work around the previous lack of in-memory data isolation.

Thanks Adam Johnson for the extensive review.

docs/internals/deprecation.txt

@@ -15,6 +15,10 @@ about each item can often be found in the release notes of two versions prior.
 See the :ref:`Django 3.2 release notes <deprecated-features-3.2>` for more
 details on these changes.
 
+* Support for assigning objects which don't support creating deep copies with
+  ``copy.deepcopy()`` to class attributes in ``TestCase.setUpTestData()`` will
+  be removed.
+
 .. _deprecation-removed-in-4.0:
 
 4.0

docs/releases/3.2.txt

@@ -195,7 +195,10 @@ Templates
 Tests
 ~~~~~
 
-* ...
+* Objects assigned to class attributes in :meth:`.TestCase.setUpTestData` are
+  now isolated for each test method. Such objects are now required to support
+  creating deep copies with :py:func:`copy.deepcopy`. Assigning objects which
+  don't support ``deepcopy()`` is deprecated and will be removed in Django 4.1.
 
 URLs
 ~~~~
@@ -255,4 +258,6 @@ Features deprecated in 3.2
 Miscellaneous
 -------------
 
-* ...
+* Assigning objects which don't support creating deep copies with
+  :py:func:`copy.deepcopy` to class attributes in
+  :meth:`.TestCase.setUpTestData` is deprecated.

docs/topics/testing/tools.txt

@@ -873,11 +873,13 @@ It also provides an additional method:
     (for instance, MySQL with the MyISAM engine), ``setUpTestData()`` will be
     called before each test, negating the speed benefits.
 
-    Be careful not to modify any objects created in ``setUpTestData()`` in
-    your test methods. Modifications to in-memory objects from setup work done
-    at the class level will persist between test methods. If you do need to
-    modify them, you could reload them in the ``setUp()`` method with
-    :meth:`~django.db.models.Model.refresh_from_db`, for example.
+    .. versionchanged:: 3.2
+
+        Objects assigned to class attributes in ``setUpTestData()`` must
+        support creating deep copies with :py:func:`copy.deepcopy` in order to
+        isolate them from alterations performed by each test methods. In
+        previous versions of Django these objects were reused and changes made
+        to them were persisted between test methods.
 
 .. _live-test-server: