[CI] group dependabot updates into fewer PRs and/or do not automatically run CI on them

[jameslamb]

Description

The description of #11001 mentions the risk of

...[Dependabot] filing a torrent of pull requests (which would explode our CI budget!)

Opening this issue to propose 2 protections against that:

1. group dependabot updates into a smaller total number of PRs

• dependabot docs: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups

2. do not automatically trigger CI, via telling dependabot to include [skip ci] in its commit messages

• GitHub Actions docs: https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs
• dependabot docs: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#commit-message
• this was done in config files in [CI] Don't run CI automatically for dependabot #9034, but once Next-generation CI/CD pipelines with RunsOn #11001 switching to GitHub Actions is merged, the [skip ci] mechanism could be used

Benefits of this work

Fewer resources (CI runners, time, money) devoted to dependabot PRs, with no loss of update frequency.

Higher release confidence (via testing more updates together at the same time before any of them are merged).

Approach

See the docs I linked above.

As a start, "group all of the Maven updates together" seems like it'd be helpful and reduce the total number of PRs noticeably. I don't have specific suggestions beyond that.

[trivialfis]

Thank you for raising the issue. It would be a huge improvement if we could avoid duplicated PRs alone. For context, the Java/Scala binding has a few different packages sharing the same set of dependencies in the same pom file. The dependent bot opens one PR for each package but the modification is the same.

See, for example, #11033 . I have to close the duplicated PRs manually.