Add Label Whitelisting functionality

[adamhf]

Fixes #179

Changes proposed in the PR:
The PR adds the ability to filter which labels on the CRD/Spec should be propagated to Kubernetes resources created by the operator via a label whitelist that specifies regexs.

By default (with no whitelist) specified the existing functionality is maintained and all labels are copied, however, once a whitelist regex is specified only labels matching it will be propagated.

This can be used to explicitly whitelist all labels via the pattern .* blacklist all labels by specifying an unmatchable pattern, or somewhere in between if you only want some propagated.

This solves our issue of our gitops operator (Flux) modifying labels on the Spec and the operator attempting to update the PDB, which are immutable in k8's < 1.15 and failing as a result.

[chusAlvarez]

Hi, lot of thanks for the contribution :). But, as the problem is the disruption bucket inmutability, Will not be delete and re-create it a more useful approach?

This way the users could change the labels and be sure they are propagated in kubernetes, as intended :)

[primeroz]

Given that this is a backward compatible change that also require a direct action to be enabled ( set the whitelisting to "something") is it such a big issue though ?

In our specific case , for example, we just don't want all this labels to propagate down since they kind of mess up a bunch of UI tools we built that never expected to have all this labels attached.

Also , still i guess in our specific case, having the "flux-cd GC" label applied to the child resources makes flux think that it owns those resources when in reality it does not ( it only owns the CRD and it should only manage that )

Also, to be honest, i don't like the idea of having any time where the PDB are not set in the cluster for a service like redis cluster , even if during normal operation this time should be very short.
Unfortunately this operation would not be atomic opening up to some edge case failures where the PDB is not set when is needed.

I personally prefer the whitelisting option so that not only we can deal with the current issue ( until 1.15 i believe ? ) but also can deal with labels themself.

[ese]

Hi @adamhf, it's ok for me. Can you resolve the conflicts?

[adamhf]

Done, apologies for the delay.

[ese]

Thank you so much for your contribution @adamhf