dependency_scanning: shouldn't set `dependencies: []`

Ask

Please update documentation so that users understand what we are doing (for speed and efficiency), there is a separate backlog item to change the behaviour.

Don't let a local optimization (template hardcoded dependencies: []) prevent a more global one provided by GitLab's Directed Acyclic Graphs.

Summary

Contrarily to sast for instance, dependency_scanning sets dependencies to an empty array.

This is annoying when favoring Directed Acyclic Graphs because one can't use needs to define upstream job(s) artifacts and has therefore to resort to override dependencies.

Steps to reproduce

1. In a first stage, have an upstream job archiving some artifacts
2. In a second stage, add any of the dependency_scanning jobs (s.a. gemnasium-maven-dependency_scanning) to the pipeline definition
3. With needs: [<upstream job>]:
   1. Override (or extend) the above job so that it needs: [<upstream job>] artifacts
   2. Run the pipeline
   3. When run, the dependency_scanning job does not retrieve artifacts from upstream job
4. With dependencies: [<upstream job>]:
   1. Now, change the above job by replacing needs: with dependencies:
   2. Run the pipeline
   3. When run, the dependency_scanning job now retrieves artifacts from upstream job

What is the current bug behavior?

needs doesn't work for dependency_scanning jobs.

What is the expected correct behavior?

needs should work for dependency_scanning jobs.

Possible fixes

Remove dependencies from dependency_scanning.

Implementation plan

Note: see comment #249569 (comment 436961514) We can't quickly address this issue so the first step is to add a note to documentation:

1. Add note to https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#limitations that dependency_scanning doesn't work with DAG right now.
2. Add a link to #257949 to show when I will be fixed.