Geo: Document push-to-secondary for SSH and HTTPS

Most GitLab team members and customers don't know how the Geo push-to-secondary proxying works. @fzimmer, @dbalexandre, and I had a deep-dive before a customer call to learn about https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6456/diffs.

The recording can be viewed by GitLab internal users in https://drive.google.com/file/d/1mWFa44bcN2i8oKJAuqhaU5T039rY33vu/view?usp=sharing.

Main things to include:

  1. The Mermaid diagrams for both HTTP and SSH proxying
  2. Distinction between HTTP and SSH proxying: one does a redirect, and the other actual proxies data.
  3. A walkthrough of the Mermaid diagrams. SSH proxying consists primarily of two main steps: proxying a info/refs request, and proxying the git-receive-pack payload.
  4. Rationale of why this works: we translate SSH to HTTPS because otherwise we'd need to figure out how to tunnel the SSH data to the primary. Not trivial to do this. We can use the standard Geo HTTPS requests behind the scenes. Worth mentioning the header munging for the SSH header.
  5. Explain custom actions: This is how gitlab-shell knows to do something "special" for a Geo transfer and to issue the HTTP GET/POST requests to the primary.
  6. Known issues
    1. We want to move this proxying from Unicorn to Workhorse: https://gitlab.com/gitlab-org/gitlab-ee/issues/7405#note_152435415
    2. Buffer the data into a file before streaming it: https://gitlab.com/gitlab-org/gitlab-ee/issues/12817
Edited by Stan Hu