Different extra options on a per-command basis

[noplanman]

As it is now, all options get applied to all commands in the borg-backup.sh and prune.sh scripts.
This only makes sense for global options, not command-specific ones.

I'd suggest to allow options parameter to be a dictionary, that allows extra options for each command. For backwards compatibility, a simple string mean global, as it is now.

(some pseudo-code)

e.g. now (options get set for every command)

- borgbackup_servers:
  - fqdn: ch-s012.rsync.net
    user: 19574
    type: rsync.net
    home: ""
    pool: borgbackup
    options: "--remote-path=borg1"

e.g. after ("global" options get set for each command, and each sub-entry only for the specific command)

- borgbackup_servers:
  - fqdn: ch-s012.rsync.net
    user: 19574
    type: rsync.net
    home: ""
    pool: borgbackup
    options:
      global: "--remote-path=borg1"
      prune: "--kep-last 10"
      check: "--verify-data"

[stroobl]

I'm not really against this idea, but what I concerned about is that it's becoming more and more complicated to debug the script (template) with this approach. The generated result should be quite clear, but the jinja2 maintenance might become an issue in the future.

[noplanman]

@stroobl Yes I understand the concern of the complexity increase.

As for the testing, shouldn't it be quite straight forward to check that the passed options have been added to the respective commands?
I must admit that the molecule testing is still a bit like magic to me 😅

Anyway, I think I'll implement something for myself and if it's stable I could make a PR. Of course I'd then look into the tests too, so this might take a while.