Add one-of matching for stop-during-backup labels

[ChrisJr404]

Closes #621

Right now a container's docker-volume-backup.stop-during-backup label value has to match the configured BACKUP_STOP_DURING_BACKUP_LABEL value exactly. Since a Docker label can only hold one value per key, a single container cannot be picked up by two backup instances that use different values.

This adds the LABEL_MATCH_BEHAVIOR option you sketched out as the second variant in the issue. It defaults to match, which keeps the current exact behavior. When set to one-of the container's label value is split on commas, so labeling a container stop-during-backup=service1,service2 lets an instance configured with either service1 or service2 stop it.

Matching already happens client side (we list all containers and filter in Go), so the Docker label filtering restrictions don't come into play here. It applies to both the stop-during-backup and stop-during-backup-no-restart labels. Added a unit test for the matcher and documented the option in the reference and the how-to.

[m90]

Thank you very much for working on this. Two rather theoretical questions from my end:

1. Would you think we should make the separator that is used for delimiting label values configurable too?
2. Is it possible to escape a comma (or any other separator if configurable) in a one-of label? I.e. can I have a label value be split into foo and bar,baz?

[m90]

I know it's a bit nonsensical by now, but all other label related settings are prefixed BACKUP, i.e. I would expect this to be BACKUP_LABEL_MATCH_BEHAVIOR. What do you think?

[ChrisJr404]

Renamed it to BACKUP_LABEL_MATCH_BEHAVIOR so it lines up with the other label settings, good call.

On the two questions:

1. I kept the separator as a fixed comma for now. Making it configurable is easy to layer on later, but I'd rather not add a second knob before there's a concrete case that needs it.
2. There's no escaping at the moment, so the value is always split on every comma. foo,bar,baz becomes three members, and you can't currently express a single member that itself contains a comma. If that turns out to matter we could add an escape like \, or the configurable separator from question 1, but my inclination is to keep it simple until someone actually hits the limit.

[m90]

My reasoning here is that I don't have any control over the consumers of the image, which means that if any of these additional options require a change in behavior, I can't add them anymore. This is a fundamental difference to an application project, where your argument makes perfect sense as you'd be the only consumer and can break things more easily. Hence, adding them might still make sense here, just so there is a set of behaviors and an interface that likely won't change anytime soon.

I'd think making the separator configurable should be rather simple, I don't know about escaping though?

[ChrisJr404]

Good questions.

1. Making the separator configurable is easy to add. I would keep the current comma as the default and expose an override so existing setups are unaffected.
2. Escaping is the harder part. Rather than invent an escaping scheme, I would lean on making the separator configurable so a value that contains a comma can pick a different delimiter that does not collide. Full quoting/escaping of an arbitrary separator inside a label value gets fiddly for little real-world gain, so I would leave it out unless a concrete need shows up.

On naming: agreed, BACKUP_LABEL_MATCH_BEHAVIOR fits the existing BACKUP_* label settings better. I will rename it to that for consistency.

[m90]

Ok, then let's make the separator configurable, shall we? Like this, you could also work around the need for escaping I guess, so we should be all good.