apimanager: Do not set APIManager controller-based ownerReferences on Secrets

[miguelsorianod]

The reason for this is that secrets are often managed by users and users
sometimes manage the secrets themselves by other controllers which also
add controller-based OwnerReferences to the secrets.
In K8s only a single controller-based OwnerReference is allowed per object, which
was preventing users to work with their own controller-based secrets.

An implication of this change is that the responsibility to cleanup
the APIManager secrets deployed belongs to the user.

This changes include an upgrade procedure to remove the APIManager
controller-based ownerReferences from existing APIManager
secrets.

[codeclimate]

Code Climate has analyzed commit 715e8ca and detected 1 issue on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	1

View more on Code Climate.

[eguzki]

Looks good.

question: what about the config maps? shouldn't be free of controller owner reference for the very same reason?

[miguelsorianod]

Looks good.

question: what about the config maps? shouldn't be free of controller owner reference for the very same reason?

At the moment we do not offer direct configuration through ConfigMaps, the ones we have listed as configurable are Secrets. We have some ConfigMaps but they are managed by the operator. If there's a configurable field in a ConfigMap it's been placed at CR level. For example, the wildcard domain.

In case in the future we add some configurable ConfigMaps we could explore this as it might make sense too. Maybe it depends on each case. Some ConfigMaps might be meant to be exclusive to the APIManager and some others "shared" with the user.