Improve Workhorse sidechannel documentation

doc/ci/large_repositories/index.md

@@ -256,8 +256,8 @@ For very active repositories with a large number of references and files, you ca
 
 - Consider using the [Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache) instead of a
   pre-clone step. This is easier to set up and it benefits all repositories on your GitLab server, unlike the pre-clone step that
-  must be configured per-repository. The pack-objects cache also automatically works for forks. For `gitlab-org/gitlab` development
-  on GitLab.com, we stopped using a pre-clone step.
+  must be configured per-repository. The pack-objects cache also automatically works for forks. On GitLab.com, where the pack-objects cache is
+  enabled on all Gitaly servers, we found that we no longer need a pre-clone step for `gitlab-org/gitlab` development.
 - Optimize your CI/CD jobs by seeding repository data in a pre-clone step with the
   [`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) of GitLab Runner. See our
   [development documentation](../../development/pipelines.md#pre-clone-step) for an overview of how we used to implement this approach on

doc/update/index.md

@@ -311,7 +311,7 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo
 
 - Connections between Workhorse and Gitaly use the Gitaly `backchannel` protocol by default. If you deployed a gRPC proxy between Workhorse and Gitaly,
   Workhorse can no longer connect. As a workaround, [disable the temporary `workhorse_use_sidechannel`](../administration/feature_flags.md#enable-or-disable-the-feature)
-  feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy.
+  feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy. If you have feedback about this change, please go to [this issue](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1301).
 
 ### 14.4.0