Readonly repos don't cache (#81674)

We say to mark repos as readonly to prevent corruption, but there's
other ways to prevent corruption that people sometimes use instead (e.g.
denying writes at the filesystem/bucket level). It's reasonable to think
that the readonly flag is redundant in that situation but it's not: they
should still mark the repo as readonly tho to bypass the cache and
re-read its contents on each access. This commit adds docs to that
effect.

Co-authored-by: James Rodewig <james.rodewig@elastic.co>

docs/reference/snapshot-restore/register-repository.asciidoc

@@ -48,7 +48,9 @@ cluster should have write access to the repository. On other clusters, register
 the repository as read-only.
 
 This prevents multiple clusters from writing to the repository at the same time
-and corrupting the repository’s contents.
+and corrupting the repository’s contents. It also prevents {es} from caching the
+repository's contents, which means that changes made by other clusters will
+become visible straight away.
 // end::multi-cluster-repo[]
 --
 

docs/reference/snapshot-restore/restore-snapshot.asciidoc

@@ -583,7 +583,9 @@ To restore a snapshot, its repository must be
 <<snapshots-register-repository,registered>> and available to the new cluster.
 If the original cluster still has write access to the repository, register the
 repository as read-only. This prevents multiple clusters from writing to the
-repository at the same time and corrupting the repository's contents.
+repository at the same time and corrupting the repository's contents. It also
+prevents {es} from caching the repository's contents, which means that changes
+made by other clusters will become visible straight away.
 
 Before you start a restore operation, ensure the new cluster has enough capacity
 for any data streams or indices you want to restore. If the new cluster has a