docs: Update all links to Django docs to point to version /3.2/.

Previously, our docs had links to various versions of the Django docs,
eg https://docs.djangoproject.com/en/1.10/topics/migrations/ and
https://docs.djangoproject.com/en/2.0/ref/signals/#post-save, opening
a link to a doc with an outdated Django version would show a warning
"This document is for an insecure version of Django that is no longer
supported. Please upgrade to a newer release!".

This commit uses a search with the regex
"docs.djangoproject.com/en/([0-9].[0-9]*)/" and replaces all matches
inside the /docs/ folder with "docs.djangoproject.com/en/3.2/".

All the new links in this commit have been generated by the above
replace and each link has then been manually checked to ensure that
(1) the page still exists and has not been moved to a new location
(and it has been found that no page has been moved like this), (2)
that the anchor that we're linking to has not been changed (and it has
been found that this happened once, for https://docs.djangoproject.com
/en/1.8/ref/django-admin/#runserver-port-or-address-port, where
/#runserver-port-or-address-port was changed to /#runserver).

docs/subsystems/caching.md

@@ -262,4 +262,4 @@ cached by clients is changed. Clients are responsible for handling
 the events, updating their state, and rerendering any UI components
 that might display the modified state.
 
-[post-save-signals]: https://docs.djangoproject.com/en/2.0/ref/signals/#post-save
+[post-save-signals]: https://docs.djangoproject.com/en/3.2/ref/signals/#post-save

docs/subsystems/client.md

@@ -29,7 +29,7 @@ The `webhook_view` auth decorator, used for most incoming
 webhooks, accepts the name of the integration as an argument and uses
 it to generate a client name that it adds to the `request_notes`
 object that can be accessed with the `request` (Django
-[HttpRequest](https://docs.djangoproject.com/en/1.8/ref/request-response/#django.http.HttpRequest))
+[HttpRequest](https://docs.djangoproject.com/en/3.2/ref/request-response/#django.http.HttpRequest))
 object via `zerver.lib.request.get_request_notes(request)`.
 
 In most integrations, `request_notes.client` is then passed to

docs/subsystems/logging.md

@@ -179,7 +179,7 @@ a new view:
 - The time when the browser was idle again after switching views
   (intended to catch issues where we generate a lot of deferred work).
 
-[django-errors]: https://docs.djangoproject.com/en/2.2/howto/error-reporting/
+[django-errors]: https://docs.djangoproject.com/en/3.2/howto/error-reporting/
 [python-logging]: https://docs.python.org/3/library/logging.html
-[django-logging]: https://docs.djangoproject.com/en/2.2/topics/logging/
+[django-logging]: https://docs.djangoproject.com/en/3.2/topics/logging/
 [sentry]: https://sentry.io

docs/subsystems/management-commands.md

@@ -62,4 +62,4 @@ to do anything special like restart the server when iteratively
 testing one, even if testing in a Zulip production environment where
 the server doesn't normally restart whenever a file is edited.
 
-[django-docs]: https://docs.djangoproject.com/en/2.2/howto/custom-management-commands/
+[django-docs]: https://docs.djangoproject.com/en/3.2/howto/custom-management-commands/

docs/subsystems/schema-migrations.md

@@ -1,7 +1,7 @@
 # Schema migrations
 
 Zulip uses the [standard Django system for doing schema
-migrations](https://docs.djangoproject.com/en/1.10/topics/migrations/).
+migrations](https://docs.djangoproject.com/en/3.2/topics/migrations/).
 There is some example usage in the [new feature
 tutorial](../tutorials/new-feature-tutorial.md).
 
@@ -164,7 +164,7 @@ an incorrect migration messes up a database in a way that's impossible
 to undo without going to backups.
 
 [django-migration-test-blog-post]: https://www.caktusgroup.com/blog/2016/02/02/writing-unit-tests-django-migrations/
-[migrations-non-atomic]: https://docs.djangoproject.com/en/1.10/howto/writing-migrations/#non-atomic-migrations
+[migrations-non-atomic]: https://docs.djangoproject.com/en/3.2/howto/writing-migrations/#non-atomic-migrations
 
 ## Schema and initial data changes
 

docs/subsystems/settings.md

@@ -26,7 +26,7 @@ convenient for:
 ## Server settings
 
 Zulip uses the [Django settings
-system](https://docs.djangoproject.com/en/2.2/topics/settings/), which
+system](https://docs.djangoproject.com/en/3.2/topics/settings/), which
 means that the settings files are Python programs that set a lot of
 variables with all-capital names like `EMAIL_GATEWAY_PATTERN`. You can
 access these anywhere in the Zulip Django code using e.g.:
@@ -146,7 +146,7 @@ accessed in initialization of Django (or Zulip) internals
 (e.g. `DATABASES`). See the [Django docs on overriding settings in
 tests][django-test-settings] for more details.
 
-[django-test-settings]: https://docs.djangoproject.com/en/2.2/topics/testing/tools/#overriding-settings
+[django-test-settings]: https://docs.djangoproject.com/en/3.2/topics/testing/tools/#overriding-settings
 
 ## Realm settings