**Note: This is a WIP PR that presently only adds the documentation for
the features so that proposal can be discussed.**

Background
==========

While trying to use zrepl in my ansible driven home lab deployment I ran
into an interesting problem. My ZFS based servers subscribe to different
sometimes overlapping roles.

Example role distribution between two servers:
```
serverA:
  - common
  - web
  - file

serverB:
  - common
  - git
  - file
```

Each role wants to create and manage a ZFS dataset with its own
replication / backup policies:
   - web: pool/web
   - git: pool/git
   - file pool/file

At present the creation of a ZFS dataset from each role role is somewhat
very easy, so to is the creation of the basic zrepl configuration file
from the "common" role.

However, when each role tries to register it's job(s) into the singular
zrepl configuration files things get tricky.

I could try adding a role at the end that hardcodes the datasets that
need to be backed up but that seems a bit hacky.

I could also use ansible's `lineinfile` task to try to idempotently add
each dataset's snapshot jobs to the zrepl configuration files but that
causes a problem:

Everytime the "common" role gets run the basic zrepl configuration file
gets re-created causing the web, git, and file roles to all register
changes as they have to re-insert all jobs back into the singular
configuration file.

Proposed Solution
=================

The proposed solution is to allow for the distribution of zrepl job
definition between multiple different YAML files that can be included
from the main zrepl configuration files.

```
global: ...
jobs:
  include: jobs.d
```

This directive would be only acceptable in the main configuration file
and is mutually exclusive with any other job definitions in the file.

To keep things lean there will be no conflict resolution provided to
users, job names must be unique across all included job YAML files.

With this feature, the above problem becomes much simpler:
   - Common: Sets up the global zrepl configuration and the include
     directive
   - web/git/file: Each manage their own datasets and create their
                   jobs.d/web.yml, jobs.d/git.yml, and jobs.d/file.yml.

As per some of the discussion items I modified the proposal to have a
special top level includes key as well as added references to handling
of specific file includes.

A relatively straight forward change that adds "include" key support in
the main configuration file.

The config parser uses the list under this key to open the included
configuration files parse them as configs and append their jobs to the
main config file.