docs/src/how-to/install/dependencies.rst: require Docker >= 20.10.14

[flokli]

glibc 2.34 uses the clone3 syscall, which is not part of the seccomp
filters that moby ships on older versions.

While as a workaround you might be able to run containers with
--privileged, it's the better call to just run a more recent Docker
runtime.

References:

• failed to build image because blocking clone3 with EPERM (it works on master) docker/buildx#772
• [v0.9] vendor: update docker to support seccomp clone3 moby/buildkit#2379
• [20.10 backport] seccomp: add support for "clone3" syscall in default policy moby/moby#42836
• [21.11] docker: 2.10.9 -> 20.10.14 (for glibc 2.34 compatiblity!) NixOS/nixpkgs#170900

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• If this PR changes development workflow or dependencies, they have been A) automated and B) documented under docs/developer/. All efforts have been taken to minimize development setup breakage or slowdown for co-workers.
• If HTTP endpoint paths have been added or renamed, or feature configs have changed, the endpoint / config-flag checklist (see Wire-employee only backend wiki page) has been followed.
• If a cassandra schema migration has been added, I ran make git-add-cassandra-schema to update the cassandra schema documentation.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.
  • If new config options introduced: added usage description under docs/reference/config-options.md
  • If new config options introduced: recommended measures to be taken by on-premise instance operators.
  • If a cassandra schema migration is backwards incompatible (see also these docs), measures to be taken by on-premise instance operators are explained.
  • If a data migration (not schema migration) introduced: measures to be taken by on-premise instance operators.
  • If public end-points have been changed or added: does nginz need un upgrade?
  • If internal end-points have been added or changed: which services have to be deployed in a specific order?