Use non-DinD mode by default for Security Products

We now have a working solution for non-DinD mode but this is currently an opt-in approach for SAST and Dependency Scanning.

Make sure everything is ready to switch in %13.0

Currently DS_DISABLE_DIND and SAST_DISABLED_DIND are false by default. These are set in Dependency-Scanning.gitlab-ci.yml and SAST.gitlab-ci.yml, respectively.

~~check usage ping, make sure it's compatible with non-DinD mode: #211621 (closed)~~
announce the change and deprecate DinD mode, to be dropped in %13.0 (next major): gitlab-com/www-gitlab-com!43694 (merged)
in %13.0, set DS_DISABLE_DIND and SAST_DISABLED_DIND to true in Dependency-Scanning.gitlab-ci.yml and SAST.gitlab-ci.yml, respectively !31588 (merged) !31589 (merged)

No change.

document changes in project detection (job conditions) #211694 (closed)
group Docker-in-Docker related variables in SAST and DS, for clarity !29045 (merged)
document Custom Analyzers documentation to cover the non-DinD setup !29121 (merged)
in %13.0, update SAST, Dependency Scanning doc, including Custom Analyzers doc, and deprecate the DinD setup !31592 (merged) !31596 (merged)

If the QA for the legacy DinD setup is missing or incomplete, this might be leading to a regression in SAST and DS when running the DinD setup, which would affect old versions of GitLb.
If there's a discrepancy in project detection, a project might get new vulnerabilities users don't want, or lose vulnerabilities it used to have.
If there's a discrepancy in vulnerability tracking or merging, the vulnerabilities might change in the UI, and vulnerability feedback might be lost.

To be investigated:

SAST and Dependency Scanning default to the setup where each scanner runs in its own CI job, and there's no Docker-in-Docker orchestrator anymore.

Edited May 18, 2020 by Fabien Catteau