Feature Request: Allow Config to Be Set to Directory

[shin-go]

Describe the bug Not a bug, but a feature request. Currently Monika is configured via YAML file(s) (typically monika.yaml) or using -c with the file or files to be used. For using Monika with a rather large set of synthetics across multiple teams/apps/services, modifying a single file can lead to headaches - particularly if there are multiple individuals making changes. A single misconfiguration by one of multiple users could cause Monika to fail to load config. Likewise, updating the CLI call to start Monika to include/exclude files is not particularly graceful.

Having Monika's -c flag accept a directory/path would gracefully solve this. The major implication with this is that it would require that top level keys in yaml files be merged rather than overwritten since as I understand it with -c accepting multiple files, the main intent there is to separate probes, notifications, etc. into their own respective scopes.

To Reproduce N/A

Expected behavior Ideally the -c arg would accept a directory (or multiple directories similarly to how -c currently accepts multiple individual YAML files), read the .yaml files located in the specified directory/directories recursively, and form a final complete yaml manifest for Monika merging top level keys that are declared in different yaml files.

Reasonably I would expect Monika to error reading the numerous yaml files if it finds declaration of the same ids under top level keys. For example:

# config1.yaml
probes:
  - id: 'poke this site'
    name: 'a synthetic'
    ...

# config2.yaml
probes:
  - id: 'poke this site'
    name: 'some other synthetic'
   ...

Otherwise, you should expect configuration across multiple yaml files with top level keys "repeated" to be valid:

# team1.yaml
probes:
  - id: 'check foobar login'
    name: 'Verify Login of Foobar'
    ...

# team2.yaml
probes:
  - id: 'check barfoo health endpoint'
    name: 'Liveness Check of Barfoo Health Endpoint'
    ...

And ultimately be compiled into a single "unified" yaml manifest that Monika loads up:

# "unified" manifest
probes:
  - id: 'check foobar login'
    name: 'Verify Login of Foobar'
    ...
  - id: 'check barfoo health endpoint'
    name: 'Liveness Check of Barfoo Health Endpoint'
    ...

Beyond ensuring there are no duplicate ids asserted in config files, Monika shouldn't be concerned with what the user(s) are defining functionally.

Additional context My org is considering Monika to replace an incumbent vendor for synthetics. Each team generally manages its own synthetics. Monika could work by having a config repository where the teams push their synthetic, notification, etc. configs centrally and Monika instances are configured up to be aware of (with some CICD automation in-between to do things like induce a config reload/restart Monika if there are config changes to be picked up).

A single yaml file approach is too brittle since it introduces the problem of if one person misconfigs, it breaks Monika for everyone. Likewise, setting additional file names with -c is cumbersome because it would mean automation then needs to manage what files are already included, what to add, and possibly what to remove from the list of config files. Ideally, in a config repository it would work as a monorepo where instances of Monika (different regions+environment) are just pointed to the relevant subdir - for example, if we ran Monika in a dev environment out of AWS EC2 us-west-2 that instance would be wired up to read config yaml files from a path like monika-config/dev/us-west-2/ whereas an instance for production in the same AWS region would be something like monika-config/prod/us-west-2/.