feat: configurable _values.yaml merging

[keeakita]

Allow a service to add a metadata file from its root: ./sentry-kube/merge.yaml, that specifies config for how conflicting keys should be handled. This enables behavior like having mappings in different files that can be merged in an append fashion.

Fixes RELENG-3

[linear]

RELENG-3 Update sentry-kube to allow splitting ownership of monolithic services

[mwarkentin]

Are there some examples of how this is expected to be used? Eg. within ops which services would use reject vs overwrite vs append? Which ones need alternate strategies (and why)?

Is there a good way for someone working on a service to understand which strategy the service is using?

What's the current behaviour? Is that changing?

[keeakita]

I've updated the unit tests which will hopefully be illuminating. The defaults aren't changing here -- the default is still reject which gives you the same current day behavior. append is what we're really after -- the ability to merge hierarchies (such as a list of worker configs). replace is only included for completeness, I'm actually struggling to think of a good use case here.

[keeakita]

As far as someone working on a service understanding the strategy, it should be pretty obvious from looking at the merge.yaml: There's a default, and then one single layer of overrides for paths (specific keys). Right now it doesn't even support any kind of recursion or paths deeper than the root. Should be pretty straightforward:

default: reject
paths:
  workers: append