Revert "Ensure CursorPagination respects nulls in the ordering field"

[max-muoto]

As @kylebebak has mentioned in #9359 attempting to accounting for nulls in the ordering field can lead to a serious performance regression in Postgres due to an index not being hit on the second query. This is blocking upgrades for some to 3.15, so putting out this PR to revert the changes. As he mentioned, it's a pretty uncommon use-case for the ordering field to be null, in the mean-time a reasonable work around would be using some sentinel value to ensure the items come last, or simply not using a nullable column.

[peterthomassen]

lgtm.

it's a pretty uncommon use-case for the ordering field to be null

Not only that; the code also doesn't work properly in all edge cases. In particular, when there are several NULL rows (possible with nulls_distinct=True), the cursor position becomes ill-defined. The problem gets worse if those rows don't all fit on one page.

To prevent unpredictable behavior, the code would have to check that the schema doesn't allow this constellation. Alternatively, one could look into index types that work better with IS NULL conditions. However, I'm not convinced that doing all this within DRF is unwarranted. It's fair enough that people have what's documented ("requires that there is a unique, unchanging ordering"), and if someone has a special case, it shouldn't be a big deal to extend the class and adapt the behavior accordingly, within their app.