chore: enable dependabot to update dependencies

[garethbowen]

Description

Attempt to enable dependabot to update dependencies automatically. This first version is a trial run. Further improvements would be to add configurations for the other package.json locations, add other registries like docker and gh actions, etc.

Configuration docs are here: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

Code review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

Compose URLs

If Build CI hasn't passed, these may 404:

• Core
• CouchDB Single
• CouchDB Cluster

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[mrjones-plip]

Nice! This might be a bit bumpy to get going (spam, false positives etc), but I think a welcome improvement in the long run.

Only question I have is I don't think we want to be bothered with major updates, yeah? Should we consider adding an update-types value to avoid that? I believe we'll need one of these for each of the three groups.

 update-types:
        - "minor"
        - "patch"

However, maybe this is OK b/c we'll get he PR opened and we can choose to ignore or schedule it?

See info on group declarations.

[garethbowen]

Only question I have is I don't think we want to be bothered with major updates, yeah?

@mrjones-plip I find it quite confusing but there are two ways to configure dependabot. The first is just to deal with known vulnerabilities - that one is already turned on and pushed a bunch of PRs yesterday. This second one is for automatically updating for non-security related reasons. I was hoping this would eliminate the need for manually updating them which is slow and error prone. I think major updates still fit into this category, though we're really leaning heavily on our testing framework to catch anywhere the dependency has broken backwards compatibility in a way that affects us. I don't think the spam will be a serious problem because majors should be rare, and it's easy to add a library to the ignore list if the breaking change will take some effort to fix. At the very least it's one way to be notified when a new major drops for any of our dependencies!

I'm still leaning towards including majors and removing them later if it turns out to be a mistake (spam or fragility).

[mrjones-plip]

@garethbowen - yeah - I can get behind your thoughts around this and including majors. Ship it!