Add updater job flag to update the dependency list without updating the dependency files

[rhyskoedijk]

What are you trying to accomplish?

Resolve dependabot/cli#360 and further progress @jakecoffman's dependabot ls CLI suggestion from dependabot/cli#325.

This change adds a new update_dependency_list_only attribute to Dependabot::Job.
When true, Dependabot::UpdateFilesCommand will exit immediately after publishing to the update_dependency_list API, skipping the call to Dependabot::Updater.run(). The option is false by default.

The change allows community users a way to use Dependabot purely for discovering dependencies, without actually updating them.

As mentioned in dependabot/cli#360, there is currently no obvious way (that I could find) for the community (outside GitHub) to use Dependabot [CLI] for security-only updates since a prerequisite of security-only updates is that the job definition contains the names of the vulnerable dependencies to be updated. The dependency names are not known until the update has started and discovery has completed, but the update cannot be started without first knowing the dependency names; catch-22.

Anything you want to highlight for special attention from reviewers?

I understand that contributions to the updater are generally not accepted and that within the GitHub hosted environment, this is a non-issue. I hope that you still consider this change (or some variation of it) to benefit community Dependabot implementations and users of Dependabot CLI.

If I have missed some obvious step that allows for security-only updates to be run without knowing the dependency names up-front, then this may not be required.

How will you know you've accomplished your goal?

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.