TPA-RFC-76: describe puppet MR workflows more explicitly (team#41971)

   not allowed to push at all. The mirror is updated with a deploy key

   that lives on the Puppet server.

## Best practices

In general, the best practice we want to establish here is this:

- Don't push directly to GitLab, unless for rare exceptions (e.g. if

  you don't have write access to the repository, in which case you

  should push to your fork anyways)

- If you *do* manage to *push* to GitLab's *main* branch (which

  shouldn't be possible), make sure you sync that branch with the one

  on the Puppet server, then push everywhere so the mirroring does not

  break

- If you push another branch, push it first to the Puppet server and

  let it mirror to GitLab, *then* make a Merge Request on GitLab to

  seek reviews

- Don't *pull* from GitLab, again unless exception (external merge

  requests being an example)

- If you *do* pull from GitLab (either by accident or in exceptional

  cases), **do** systematically review the patch pulled from GitLab

  before pushing back to the Puppet server

- To merge a feature branch, pull it locally, then review the changes

  in detail, *merge locally* (i.e. not on GitLab), then push back to

  the Puppet server. Again, ideally pull from the Puppet server, but

  if it's on GitLab only, then from GitLab.

# Alternatives

## Making repository public