Sinker should add a ResourceSync as an owner of local-cluster target objects

[Cannon Palms]

Sinker can perform two actions, each in one of two contexts: It can (1) create and (2) update an object in either a (1) remote cluster or (2) the local cluster.

Let's ignore the two cases that involve a target object in a remote cluster, because we cannot take cross-cluster owner references.

When a ResourceSync creates a new target object in the local cluster, we should take ownership of that new object. This ensures proper garbage collection in this case. Default Kubernetes DELETE behavior is for deletes to propagate from owning objects to dependent/owned objects.

There are two open questions here, in my opinion:

1. Should we add the ResourceSync as an owner of any local-cluster target we modify, or should we only take ownership of objects we ourselves create? Perhaps instead we should take ownership of any object--created by us or not--that has no existing owner references? Answering this question involves some exploration of how garbage collection / delete propagation functions in multi-owner situations.
2. Are there any circumstances in which is is appropriate to take not only an owner reference on a target object but also a controller reference? Perhaps controller references fit those cases where sinker creates an object in the local cluster? Does this decision impact garbage collection / delete propagation at all, or is it just symbolic?

[Luke Bond]

@zach-robinson-dev would you say this is fixed now? please close if so