docs: Update production docs for local S3 caching.

docs/production/requirements.md

@@ -202,8 +202,9 @@ installing Zulip with a dedicated database server.
 - **Disk for application server:** We recommend using [the S3 file
   uploads backend][s3-uploads] to store uploaded files at scale. With
   the S3 backend configuration, we recommend 50 GB of disk for the OS,
-  Zulip software, logs and scratch/free space. Disk needs when
-  storing uploads locally
+  Zulip software, logs and scratch/free space. Because uploaded files
+  are cached locally, you may need more disk space if you make heavy
+  use of uploaded files.
 
 - **Disk for database:** SSD disk is highly recommended. For
   installations where most messages have <100 recipients, 10 GB per 1M

docs/production/security-model.md

@@ -219,25 +219,12 @@ strength allowed is controlled by two settings in
   file to be accessed by the unauthorized user. Of course, any
   such authorized user could have just downloaded and sent the file
   instead of the URL, so this is arguably pretty good protection.)
-  However, to help protect against accidental
-  sharing of URLs to restricted files (e.g. by forwarding a
-  missed-message email or leaks involving the Referer header), we
-  provide additional layers of protection in both backends as well.
 
-  In the Zulip S3 backend, the random URLs to access files that are
-  presented to users don't actually host the content. Instead, the S3
-  backend verifies that the user has a valid Zulip session in the
-  relevant organization (and that has access to a Zulip message linking to
-  the file), and if so, then redirects the browser to a temporary S3
-  URL for the file that expires a short time later. In this way,
-  possessing a URL to a secret file in Zulip does not provide
-  unauthorized users with access to that file.
-
-  We have a similar protection for the `LOCAL_UPLOADS_DIR` backend.
-  Every access
-  to an uploaded file has access control verified (confirming that the
-  browser is logged into a Zulip account that has received the
-  uploaded file in question).
+  However, to help protect against accidental sharing of URLs to
+  restricted files (e.g. by forwarding a missed-message email or leaks
+  involving the Referer header), every access to an uploaded file has
+  access control verified (confirming that the browser is logged into
+  a Zulip account that has received the uploaded file in question).
 
 - Zulip supports using the [go-camo][go-camo] image proxy to proxy content like
   inline image previews, that can be inserted into the Zulip message feed by

docs/subsystems/performance.md

@@ -283,15 +283,9 @@ scalability cost of fetching message history dramatically.
 Requests to fetch uploaded files (including user avatars) account for
 about 5% of total HTTP requests. Zulip spends consistently ~10-15ms
 processing one of these requests (mostly authorization logic), before
-handing off delivery of the file to `nginx` or S3 (depending on the
-configured [upload backend](../production/upload-backends.md)).
-
-We can significantly reduce the volume of these requests in large
-production Zulip servers by fixing [Zulip's upload authorization
-strategy preventing browser caching of
-uploads](https://github.com/zulip/zulip/issues/13088), since many of
-them result from a single client downloading the same file repeatedly
-as it navigates around the app.
+handing off delivery of the file to `nginx` (which may itself fetch
+from S3, depending on the configured [upload
+backend](../production/upload-backends.md)).
 
 ### Sending and editing messages
 

docs/tutorials/life-of-a-request.md

@@ -22,8 +22,7 @@ are in your Git checkout under `static`, and are served unminified.
 
 [served-directly]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app
 
-Static files include JavaScript, css, static assets (like emoji, avatars),
-and user uploads (if stored locally and not on S3).
+Static files include JavaScript, CSS, and static assets (like emoji, avatars).
 
 File not found errors (404) are served using a Django URL, so that we
 can use configuration variables (like whether the user is logged in)