[ci] Add dependabot configuration for updating git submodules

[borchero]

Implementation of this comment.

In contrast to CI updates, I refrained from grouping together updates of git submodules to isolate potential issues to individual dependencies. If this creates too many PRs, we can, of course, change this behavior at a later point.

[jameslamb]

Thanks for this!

I'm generally very supportive of doing this, but I have a question... what tells dependabot that there's a new version?

Things I would not support triggering on:

• new commit on default branch

Things I would support triggering on:

• new tag pushed
• stable or similar tag ref updated (as @StrikerRUS noted in List of dependencies that should be updated from time to time #3763)
• new release cut in source code management (GitHub / GitLab)

The docs at https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file have 0 details on package-ecosystem: gitsubmodule, and I haven't yet found an answer to this in my searching around the internet.

I found dependabot/dependabot-core#1639 which seems to suggest that it is based on latest commit, but not sure if that just is a stale issue that hasn't been closed yet.

It does some like maybe renovate supports watching for new git` tags, basedo n the existence of https://docs.renovatebot.com/modules/datasource/git-tags/. Maybe we could try that?

Well why not just update to the latest commit?

I'm mostly just repeating things @msarahan taught me here. In general a new non-tagged commit is not the same as a "release", because:

• releases tend to have been put through some additional, more expensive testing that other commits have not
• releases may include changes to documentation or configuration which are only pushed to source control right before release time
  • like setting CMake build type to Release to remove debugging symbols or assertions
  • like adding "added/removed in version {version}" things to docs and log messages

[StrikerRUS]

I like this automatization! Thanks for working on it @borchero !

Also I'm totally agree with @jameslamb that we should have more granular control over updates compared to simple "update on every commit".

[jameslamb]

@borchero it's been a couple months since this PR was opened and @StrikerRUS and I left feedback... can you please either come back to work on this or let us know you aren't interested any more and close it?