Do not auto-approve dependabot PRs, and add cooldown to dependabot

[ludfjig]

Automatically merging PRs is not a good idea security-wise, especially given the many supply chain attacks these days. Having a human review the diff of an updated crate is always good to make sure it's not been compromised. This PR removes auto-approving PRs by our bot and also adds a cooldown to dependabot which is good practice in general.

I also considered just adding a dependabot cooldown, and also only auto-merging patch/minor bumps, but ultimately settle on this which I think is the better approach.

Note: The bot is still used in dep_update_guest_locks.yml

[Copilot]

Pull request overview

This PR removes the repository automation that auto-approved/auto-merged Dependabot PRs (to require human review) and adds a Dependabot “cooldown” period to reduce update churn while still allowing Dependabot to operate normally.

Changes:

• Deleted the scheduled GitHub Actions workflow that auto-approved/auto-merged Dependabot PRs.
• Removed the dev/auto-approve-dependabot.sh script used by that workflow.
• Added a 7-day Dependabot cooldown across configured ecosystems/directories.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
dev/auto-approve-dependabot.sh	Removed the Dependabot auto-approval/auto-merge script to require human review.
.github/workflows/auto-merge-dependabot.yml	Removed the scheduled workflow that used the script to auto-approve/auto-merge Dependabot PRs.
.github/workflows/dep_update_guest_locks.yml	Removed a comment referencing the deleted auto-merge workflow (no functional change).
.github/dependabot.yml	Added cooldown: default-days: 7 to reduce update noise and avoid immediate adoption of freshly-released versions.

[jsturtevant]

It seems this is a wise choice in the current environment, but it will make a little bit more work for maintainers. I would leave it for others to look at too and give some comments or approve

[simongdavies]

I am in 2 minds about this, generally agree with the cooldown changes (although we should probably think about if we want different settings for major/minor/patch).

I don't know about having manual review, besides the overhead, what is the expectation on a reviewer? How likely is it that one of us will find a supply chain attack in a dependency that has presumably evaded the maintainers of the dependency? If a dependency has been compromised then I guess it will be yanked (and dependabot will behave appropriately?