[Grouped Updates] Refactor the DependencyGroupEngine into an object, Improved logging for empty groups

[brrygrdn]

Addresses #7075 (comment)

We currently implement the DependencyGroupEngine as a module which uses class variables to act a little like a singleton as we weren't sure how it would be injected into the Updater when we created it so we defaulted to global scope.

With much of the architecture now settled, it makes sense to move away from this global object to instantiate it immediately after we parse the project's manifest files when creating a the DependencySnapshot

This ensures that any fatal issues parsing the rules can be handled here:

dependabot-core/updater/lib/dependabot/update_files_command.rb

Lines 15 to 25 in 779657e

	begin
	dependency_snapshot = Dependabot::DependencySnapshot.create_from_job_definition(
	job: job,
	job_definition: Environment.job_definition
	)
	rescue StandardError => e
	handle_parser_error(e)
	# If dependency file parsing has failed, there's nothing more we can do,
	# so let's mark the job as processed and stop.
	return service.mark_job_as_processed(Environment.job_definition["base_commit_sha"])
	end

Improved handling of empty groups

Right now we quietly swallow any groups which are defined but do not correspond to any dependencies which means we fail over to doing single updates without calling out why the group wasn't attempted.

As part of this work, it became much easier to warn during the job startup when we find an empty group, which results in us logging a message like:

Please check your configuration as there are groups no dependencies match:
- group-a
- group-b

This can happen if:
- the group's 'pattern' rules are misspelled
- your configuration's 'allow' rules do not permit any of the dependencies that match the group
- the dependencies that match the group rules have been removed from your project

At runtime, we will now acknowledge the empty groups exist and specifically log that we are skipping them like so:

Skipping update group for 'group-a' as it does not match any allowed dependencies.

Rebasing

It is possible for us to find when rebasing a grouped PR that the group definition has now become empty due to all dependencies matching the group having been removed.

Rather than the job being a silent no-op, we will now close the pull request with the following comment:

None of your dependencies match this group anymore, you may need to update your configuration file to remove it or change its rules.

TODO

• Ship a change to the Dependabot service so it is aware of the dependency_group_empty close reason

[jakecoffman]

LGTM other than the smoke test failures, makes sense 👍

[brrygrdn]

The remaining smoke test failure is actually an issue with the test rig, which I've fixed here: dependabot/smoke-tests#103

This does make me 🤔 about the decision to always parse the group configuration immediately after parsing dependencies in every job as some jobs may not actually involve using the groups like rebases but I think the problem here was ultimately a mandatory array being nil which is a defect we won't see in the real world.

We could push the evaluation of groups later but since it only warns it still seems better to me to perform it at the same call sight as evaluating the manifests and parsing dependencies. In future it might make sense to move the operation split up so we don't bother parsing the files when we are told to update a specific dependency/and or rebase a PR?

[brrygrdn]

@jakecoffman This should be good to go now