Document runner 4 and 5, regenerate the 28.2.0 api documents (#599)

The 28.2.0 bump in #594 only changed the version string of the api documents, so they still listed the 28.1.0 endpoints. They are now regenerated from v28.2.0 (mostly new `423 repoArchivedError` responses).

The runner docs stopped at 3.3.0 while the runner is at 5.1.1:

- cut the runner `4` and `5` series, `/runner/` now serves 5.1.1 and `/runner/4/` 4.1.0, the `3` series is bumped to 3.5.0
- series specific image tags and versions in the new copies, the `3` series no longer claims the `latest` tag
- 4.0 and 5.0 sections in the upgrade guide, and the Git 2.34.1 requirement of 5.0 in the requirements
- regenerated every reference page from the newest stable tag of its series

Reviewed-on: https://gitea.com/gitea/docs/pulls/599
Reviewed-by: TheFox0x7 <[email protected]>

runner-docs_versioned_docs/version-5/proxy.md

@@ -0,0 +1,46 @@
+---
+sidebar_position: 6
+---
+
+# Proxies
+
+The runner reads the usual proxy variables from its own environment and passes them on to every job:
+
+```sh
+http_proxy=http://proxy.example:3128
+https_proxy=http://proxy.example:3128
+no_proxy=gitea.internal,.example.local
+```
+
+Set them where the process is started — `Environment=` in a systemd unit, `docker run -e`, or `env:` in Kubernetes. They are used for the runner's own requests and are given to jobs in both lower and upper case.
+
+## What is exempted automatically
+
+These are added to `no_proxy` for jobs, so they are always reached directly:
+
+- the cache server
+- `localhost`, `127.0.0.1` and `::1`
+- the job's service containers
+- the Docker daemon, when it is reached over `tcp://`
+
+The Gitea instance is **not** added. Add it to `no_proxy` yourself if it should be reached directly.
+
+## Overriding per job or per runner
+
+| Scope | Where to set it |
+| --- | --- |
+| one step | the step's `env:` |
+| one job | the job's `container.env` |
+| the whole runner | `runner.envs` in the config; a `no_proxy` set there is added to the list above instead of replacing it |
+
+Setting proxy variables at workflow or job level (outside `container.env`) has no effect.
+
+## The Docker daemon needs its own setting
+
+Images are pulled by the daemon, not by the runner, so the daemon needs its own proxy configuration. In the `dind` images the daemon shares the container's environment and picks the variables up; for any other daemon see [the Docker documentation](https://docs.docker.com/engine/daemon/proxy/). The runner logs a warning at startup when it has a proxy configured and the daemon does not.
+
+Dockerfile actions are built with these variables passed as build arguments, so their `RUN` steps can reach the network.
+
+## Credentials in proxy URLs
+
+A password inside a proxy URL is masked in job logs, but any step can still read it: the step is given the proxy URL in its environment. Prefer a proxy that does not need credentials, or one that authenticates by source address.