links: Replace all references to Django docs to link to /3.2/ version.

Previously, our codebase contained links to various versions of the
Django docs, eg https://docs.djangoproject.com/en/1.8/ref/
request-response/#django.http.HttpRequest and https://
docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SERVER_EMAIL
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!".

Most of these links are inside comments.

Following the replacement of these links in our docs, this commit uses
a search with the regex "docs.djangoproject.com/en/([0-9].[0-9]*)/"
and replaces all matches 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 no anchor has been changed like this).

One comment where we mentioned a Django version in text before linking
to a page for that version has also been changed, the comment
mentioned the specific version when a change happened, and the history
is no longer relevant to us.

templates/zerver/api/incoming-webhooks-walkthrough.md

@@ -143,7 +143,7 @@ You should name your webhook function as such
 integration and is always lower-case.
 
 At minimum, the webhook function must accept `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), and `user_profile` (Zulip's user object). You may also want to
 define additional parameters using the `REQ` object.
 

zerver/lib/webhooks/common.py

@@ -141,7 +141,7 @@ def check_send_webhook_message(
 def standardize_headers(input_headers: Union[None, Dict[str, Any]]) -> Dict[str, str]:
     """This method can be used to standardize a dictionary of headers with
     the standard format that Django expects. For reference, refer to:
-    https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.headers
+    https://docs.djangoproject.com/en/3.2/ref/request-response/#django.http.HttpRequest.headers
 
     NOTE: Historically, Django's headers were not case-insensitive. We're still
     capitalizing our headers to make it easier to compare/search later if required.

zerver/models.py

@@ -1705,7 +1705,7 @@ class UserProfile(AbstractBaseUser, PermissionsMixin, UserBaseSettings):
     #
     # In Django, the convention is to use an empty string instead of NULL/None
     # for text-based fields. For more information, see
-    # https://docs.djangoproject.com/en/1.10/ref/models/fields/#django.db.models.Field.null.
+    # https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.null.
     timezone: str = models.CharField(max_length=40, default="")
 
     AVATAR_FROM_GRAVATAR = "G"

zerver/views/user_settings.py

@@ -233,8 +233,8 @@ def json_change_settings(
             raise JsonableError(_("New password is too weak!"))
 
         do_change_password(user_profile, new_password)
-        # In Django 1.10, password changes invalidates sessions, see
-        # https://docs.djangoproject.com/en/1.10/topics/auth/default/#session-invalidation-on-password-change
+        # Password changes invalidates sessions, see
+        # https://docs.djangoproject.com/en/3.2/topics/auth/default/#session-invalidation-on-password-change
         # for details. To avoid this logging the user out of their own
         # session (which would provide a confusing UX at best), we
         # update the session hash here.

zproject/computed_settings.py

@@ -240,7 +240,7 @@ SILENCED_SYSTEM_CHECKS = [
     # `unique=True`.  For us this is `email`, and it's unique only per-realm.
     # Per Django docs, this is perfectly fine so long as our authentication
     # backends support the username not being unique; and they do.
-    # See: https://docs.djangoproject.com/en/2.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD
+    # See: https://docs.djangoproject.com/en/3.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD
     "auth.W004",
     # models.E034 limits index names to 30 characters for Oracle compatibility.
     # We aren't using Oracle.

zproject/default_settings.py

@@ -376,7 +376,7 @@ if TYPE_CHECKING:
 
 JWT_AUTH_KEYS: Dict[str, "JwtAuthKey"] = {}
 
-# https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SERVER_EMAIL
+# https://docs.djangoproject.com/en/3.2/ref/settings/#std:setting-SERVER_EMAIL
 # Django setting for what from address to use in error emails.
 SERVER_EMAIL = ZULIP_ADMINISTRATOR
 # Django setting for who receives error emails.

zproject/prod_settings_template.py

@@ -44,7 +44,7 @@ EXTERNAL_HOST = "zulip.example.com"
 ## representing the host/domain names that your users can enter in
 ## their browsers to access Zulip.  This is a security measure; for
 ## details, see the Django documentation:
-## https://docs.djangoproject.com/en/2.2/ref/settings/#allowed-hosts
+## https://docs.djangoproject.com/en/3.2/ref/settings/#allowed-hosts
 ##
 ## Zulip automatically adds to this list 'localhost', '127.0.0.1', and
 ## patterns representing EXTERNAL_HOST and subdomains of it.  If you are

zproject/sentry.py

@@ -79,7 +79,7 @@ def setup_sentry(dsn: Optional[str], environment: str) -> None:
     )
 
     # Ignore all of the loggers from django.security that are for user
-    # errors; see https://docs.djangoproject.com/en/3.0/ref/exceptions/#suspiciousoperation
+    # errors; see https://docs.djangoproject.com/en/3.2/ref/exceptions/#suspiciousoperation
     ignore_logger("django.security.SuspiciousOperation")
     ignore_logger("django.security.DisallowedHost")
     ignore_logger("django.security.DisallowedModelAdminLookup")