Tests rely on unspecified row order of SELECT without ORDER BY

[Yaroslav K]

Many (~70) tests assert a specific row order for querysets whose SQL has no
ORDER BY. SQL standard does not define that order.

On PostgreSQL the rows usually arrive in physical storage order, which
on a freshly loaded table matches insertion order -- so these assertions
pass by coincidence rather than by contract. That breaks when rows are
updated or deleted and the space is reused, or when the planner picks a
different access path such as an index scan. A test like this can start
failing with no change to Django or to the test itself.

Proposed solution:

1. add order_by() where the asserted sequence is meaningful
2. use assertCountEqual() otherwise

Found by running the suite under
​pg_disorder.

[Jacob Walls <jacobtylerwalls@…>]

In 7576781:

Fixed #37255 -- Avoided relying on implicit SELECT ordering in tests.

Many (~70) tests assert a specific row order for querysets whose SQL has no
ORDER BY. SQL standard does not define that order.

On PostgreSQL the rows usually arrive in physical storage order, which
on a freshly loaded table matches insertion order -- so these assertions
pass by coincidence rather than by contract. That breaks when rows are
updated or deleted and the space is reused, or when the planner picks a
different access path such as an index scan. A test like this can start
failing with no change to Django or to the test itself.

The patch made sure that most of these tests do not
rely on unspecified unordered selection order.